RE: [trans-ws] XLIFF schema

[Stephen.Flinter@connectcgs.com]

Peter,

I assume that you're referring to the
phase-name attribute of the ElemType_count element?

        <xsd:complexType
name="ElemType_count">
           
    <xsd:simpleContent>
           
            <xsd:extension
base="xsd:string">
           
               
    <xsd:attribute
name="count-type"
type="xlf:AttrType_count-type"
use="optional"
/>
           
               
    <xsd:attribute
name="phase-name"
type="xsd:string"
use="optional"
/>
           
               
    <xsd:attribute
name="unit"
type="xlf:AttrType_unit"
use="optional"
default="word"
/>
           
            </xsd:extension>
           
    </xsd:simpleContent>
        </xsd:complexType>

If so, as I've just said above, "phase-name"
is an attribute, not a child element.  Also, phase-name has type of
xsd:string, which means that it can respresent any legal XML string.

I came across this mail (http://lists.oasis-open.org/archives/xliff/200212/msg00033.html)
which suggests a relationship between the phase-name attribute of the ElemType_count
element type and the ElemType_phase element type.  However, I can
see nothing in the XLIFF schema that enforces that relationship - it's
purely a semantic one.  Is this a correct interpretation?

<aside>
        Also,
I've noticed in the XLIFF schema that phase-name is variously given types
of xsd:string, and xsd:NMTOKEN.  Is this deliberate?
</aside>

Anyway, back to the point.  We
we have two options:
        1.
we can either take the count-group and count elements as they are in the
XLIFF schema, and choose to ignore the phase-name attribute
        2.
or we can copy the parts of the XLIFF schema that are relevent to us, and
to transplant them directly into the TransWS schama.

If we take the second option, we should
get a count-group structure that exactly fits our need, but it means that
it won't correspond exactly with the XLIFF concept of count-group.  Perhaps
his is desirable, I'm not sure.

On a related note, the AttrType_count-type
type is a union of a bunch of different enumerated lists:

        <xsd:simpleType
name="AttrType_count-type">
           
    <xsd:annotation>
           
            <xsd:appinfo>
           
               
    <xyz:user-defined>yes</xyz:user-defined>
           
            </xsd:appinfo>
           
    </xsd:annotation>
           
    <xsd:union
memberTypes="xlf:restypeValueList
xlf:count-typeValueList xlf:datatypeValueList
           
                     
  xlf:stateValueList xlf:state-qualifierValueList xlf:XTend"
/>
        </xsd:simpleType>

Of these, only count-typeValueList (and
possibly state-qualifierValueList) appear to be truly relevent.  Can
somebody explain the relevance of the others, and whether we want to preserve
them into the TransWS schema?

Steve

---------------------------------------------
Stephen Flinter
Connect Global Solutions
[t] +353 (0)1 882 9038
[f] +353 (0)1 882 9050
[m] +353 87 798 1228
[e] stephen.flinter@connectcgs.com
[w] www.connectcgs.com
--------------------------------------------

"Reynolds, Peter" <Peter.Reynolds@bowneglobal.ie>

15/10/2004 16:44

To	<Stephen.Flinter@connectcgs.com>, <trans-ws@lists.oasis-open.org>
cc
Subject	RE: [trans-ws] XLIFF schema

Hi Stephen,
 
I have a question to add rather
than an answer. What do we do with the phase element which is a child element
to the count element.
 
Peter,

---

From: Stephen.Flinter@connectcgs.com
[mailto:Stephen.Flinter@connectcgs.com] 
Sent: 15 October 2004 12:58
To: trans-ws@lists.oasis-open.org
Subject: [trans-ws] XLIFF schema


All, 

I'm currently working on modifying the WSTrans XML Schema document to take
account of the count-group issue as recently agreed.  

My preference is to reference and import the XLIFF schema document directly
(as opposed to copying the relevant element definitions into my schema
doc).  However, when I do that I am getting errors from my XML schema
validator that the XLIFF schema is not valid.  One potential cause
of this is the <documentation> elements that are used in the schema.
 For example: 

        <xsd:enumeration
value="paramnotes">
                <xsd:annotation>
                    
   <xsd:documentation>
                    
           Indicates notes pertaining to
the parameters in the 
                    
           <source>.
                    
   </xsd:documentation>
                </xsd:annotation>
        </xsd:enumeration>

According to my understanding of the XML schema the <documentation>
element accepts any well formed XML text.  This includes straightforward
text, and other XML markup, as long as it's well formed.

The example above is NOT well formed, as you have a <source> tag
within the <documentation> element, but no closing </source>
tag. 

To my mind you either have to supply a closing </source> tag, or
escape the angle brackets: &lt;source&gt; (which is not really
readable). 

Is this an issue that the XLIFF group is aware of?  I haven't posted
this message to the XLIFF group, as I haven't really followed the discussions
there, and don't want to make an ass of myself if this has already been
discussed (or my understanding of XML schema is wrong :-). 

BTW, I've been using this schema, as referenced by the XLIFF homepage:
http://www.oasis-open.org/committees/xliff/documents/xliff-core-1.1.xsd

Anyone know what the score is? 

Steve 

PS on a separate note, I feel that the namespace that you've chosen for
schema is not ideal: 

        urn:oasis:names:tc:xliff:document:1.1.

Most Java based libraries for generating an object-based representation
of an XML schema use the schema namespace as the package name for the generated
classes.  The XLIFF namespace does not translate to a valid Java (or
C#) package name - the problem is with the final 1.1.

If possible, I would suggest that you consider changing the namespace to:

        urn:oasis:names:tc:xliff:document:v1_1

---------------------------------------------
Stephen Flinter
Connect Global Solutions
[t] +353 (0)1 882 9038
[f] +353 (0)1 882 9050
[m] +353 87 798 1228
[e] stephen.flinter@connectcgs.com
[w] www.connectcgs.com
--------------------------------------------

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************