OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XLIFF schema changes


All,

 

Attached is a zip with 4 schema files.

 

xliff-core-1.1-20060222.xsd

 

The tool-id attribute was missing from the elements that should have it (except the ‘tool’ tag).

 

xliff-core-1.2-20060222.xsd

 

The tool-id attribute was missing from the elements that should have it (except the ‘tool’ tag).

Constraints were also added.

 

xliff-strict-1.1-20060222.xsd

 

The tool-id attribute was missing from the elements that should have it (except the ‘tool’ tag).

Constraints were also added.

Deprecated elements and attributes are prohibited.

 

xliff-strict-1.2-20060222.xsd

 

The tool-id attribute was missing from the elements that should have it (except the ‘tool’ tag).

Constraints were also added.

Deprecated elements and attributes are prohibited.

 

 

The missing tool-id attribute is just a defect in the schema. Not sure if we need to re-issue 1.1 or not. It’s not a spec change, just a fix to the xsd file.

 

Constraints were added as defined in the specification. This provides more complete validation. I didn’t bother adding them to 1.1 because 1.2 is close to being adopted and it’s not a defect.

 

The constraint for the xid attribute to refer to the id attribute in a trans-unit or bin-unit element could not be implemented. The trans-unit/bin-unit id does not need to be unique, so the xid attribute may refer to more than one trans-unit/bin-unit element. We can’t change the id attribute to be unique without breaking compatibility. Presumably, the xid would refer to an id that is unique within its parent body, group, or bin-unit element.

 

‘Strict’ versions of the schemas are included that detect deprecated elements and attributes. (I was using the prop-group/prop elements and ts attribute and wanted to validate my changes to remove them). Though not normative, I recommend providing them to the public similar to the way W3C provides both transitional and strict schemas for XHTML.

 

At the minimum, I recommend that the TC adopt the changes/fixes to the xliff-core-1.2-20060222.xsd schema.

 

 

 

Regards,

 

Doug Domeny

Software Analyst

 

Ektron, Inc.

+1 603 594-0249 x212

http://www.ektron.com

 

 

XliffSchemas20060222.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]