csprd02 comment 138 - schema ambiguity in core and matches

["Tom Comerford" <tom@supratext.com>]

Hi all,

 

Comment 138 describes the issue with Unique Particle Attribution: within <group>, <unit>, or <match> in an XLIFF document, any occurrence of an optional element from a module will cause validation to fail because the element is ambiguous. The original comment is below. Note that <file> also references optional module elements, but there’s no ambiguity because <unit> or <group> is required before the extension point.

 

I propose to remove these specific module elements from the specification. This is the proper solution, syntactically, as it eliminates the ambiguity. The module elements are still permitted via the extension point. If there’s no dissent, I’ll complete this before our next meeting.

 

This issue also insinuates a more general philosophical point. Since an extension point allows elements or attributes from other namespaces, then explicitly referencing those elements or attributes is redundant. Should those references be removed as well?

 

Thanks,

 

Tom

 

 

 

Subject: [xliff-comment] schema ambiguity in core and matches

 

Element references in the following three element definitions are syntactically ambiguous within the XML schema language:

 

element definition for xlf:group

references:

                mda:metadata

                slr:data

                val:validation

 

element definition for xlf:unit

references:

                mtc:matches

                gls:glossary

                mda:metadata

                res:resourceData

                slr:data

                val:validation

 

element definition for mtc:match

references:

                xlf:originalData

                mda:metadata

 

Each element reference is optional in the given context. In all three element definitions these references are followed by <xs:any>, which allows any element from any namespace, including any of the referenced elements. This redundancy is explicable; the element references show implementers how those elements can be used. It’s also exemplary, by which I mean to suggest that they could as easily be shown in examples and/or in the prose descriptions of how the respective elements can be used.

 

The reason that they SHOULD be in the documentation, and MUST NOT be in the schema, is this: A validating parser cannot unambiguously determine whether any occurrence of the referenced element satisfies the explicit reference, or the wild-card <xs:any> token. Thus, strict validation of the schema fails.

 

 

 

Tom Comerford
tom@supratext.com

+1 856 787 9090

 

Supratext LLC
43 Michaelson Drive
Mount Laurel, NJ 08054

 

www.supratext.com