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

Hi Tom,

That make sense to me: from the core viewpoint modules are like extended elements. Having them listed in the core as distinct
features is strange.

Would something like NVDL (http://www.nvdl.org/) allow to describe how the modules can/should be placed in the core, without
interfering with the core?

-ys


From: Tom Comerford [mailto:] 
Sent: Friday, October 4, 2013 3:25 PM
To: 
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

+1 856 787 9090

Supratext LLC
43 Michaelson Drive
Mount Laurel, NJ 08054

www.supratext.com