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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Tom, all

I tend to agree with your solution.

It fits with my long-standing view that, from the viewpoint of a core processor, modules cannot be different from extensions.

This would leave us with one issue: The text of each module specification can detail where the module's elements are expected to go
(as constraint and PRs), but there is no way to validate that using an XSD schema. That means modules would have to be validated at
least partially through parsing. Or could something like Schematron or/and NVDL be helpful?

Cheers,
-yves


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Tom Comerford
Sent: Monday, November 11, 2013 8:21 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] csprd02 comment 138 - schema ambiguity in core and matches

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