FW: "Transparent" Change for Next Update to XLIFF XSD

Submitted for review.

 

From: Doug Domeny 

Sent: Monday, November 23, 2009 1:01 PM

To: 'Lieske, Christian'

Cc: 

Subject: RE: "Transparent" Change for Next Update to XLIFF XSD

 

I’ve attached the 1.2.1
schemas with both global types and global elements.

 

Doug

 

From: Lieske, Christian
[mailto:] 

Sent: Monday, November 23, 2009 8:17 AM

To: Doug Domeny

Cc: 

Subject: "Transparent" Change for Next Update to XLIFF XSD

 

Hi Doug,

 

Facing my next XLIFF-related work item, I
dare to approach you again with a question …

 

While working with the XLIFF XSD, I
discovered that it would be quite handy if the XLIFF elements would be defined
by means of types, rather than being defined “inline”.

 

Example:

 

With “type”

 

<xsd:element name="header" type="xlf:headerType"/>

 

“Inline” (status quo)

 

        <xsd:element name="header">

               
<xsd:complexType>

                       
<xsd:sequence>

                               
<xsd:element name="skl" type="xlf:ElemType_ExternalReference" minOccurs="0"/>

                               
<xsd:element ref="xlf:phase-group" minOccurs="0"/>

                               
<xsd:choice minOccurs="0" maxOccurs="unbounded">

                                       
<xsd:element name="glossary" type="xlf:ElemType_ExternalReference"/>

                                       
<xsd:element name="reference" type="xlf:ElemType_ExternalReference"/>

                                       
<xsd:element ref="xlf:count-group"/>

                                       
<xsd:element ref="xlf:note"/>

                                       
<xsd:element ref="xlf:tool"/>

                               
</xsd:choice>

                               
<xsd:any namespace="##other" processContents="strict" minOccurs="0" maxOccurs="unbounded"/>

                       
</xsd:sequence>

               
</xsd:complexType>

        </xsd:element>

 

Working with “types” would
amongst others allow one to use the XSD “redefine” mechanism. This
mechanism in turn is very helpful to enact checking mechanisms very easily
(example: I could create an XSD which does not allow some of the XLIFF
attribute values for “restype” or “datatype”).

 

From my understanding, switching to
“type” would be transparent: the structure defined by the XSD would
not be changed. 

 

I take this to you first, since amongst others
someone would have to make the change to the XSD – and my assumption is
that you would be in a good position to do this.

 

If you would be in favor, and available to
make the change, I would officially make the request to the TC to target this
as part of the upcoming errata. 

 

Cheers,

Christian

 

Christian Lieske

Knowledge Architect

SAP Language Services (SLS)

SAP Globalization Services

SAP AG

Raiffeisenring 44

D-68789 St. Leon-Rot

Germany

T +49 (62 27) 7 - 6 13 03

F +49 (62 27) 7 – 2 54 18

mail to:

www.sap.com 

Pflichtangaben/Mandatory
Disclosure Statements: http://www.sap.com/company/legal/impressum.epx

Diese E-Mail kann Betriebs- oder
Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail
ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen
Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise
confidential information. If you have received this e-mail in error, you are
hereby notified that any review, copying, or distribution of it is strictly
prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation.

 

 

 

xsdTyped.zip