proposed solutions for CSPRD 138 (Unique Particle Attribution)

Hello all,

Following up on our discussion during yesterday’s meeting, we have three possible solutions for the Unique Particle Attribution condition for XLIFF documents that are meant to conform to the schema. The purpose of this email is to elicit discussion of the different approaches, toward building consensus around one solution.

Previous threads relevant to this issue:

https://lists.oasis-open.org/archives/xliff-comment/201310/msg00025.html (this became CSPRD02 comment 138)

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201311/msg00052.html

More background on Unique Particle Attribution:

http://www.w3.org/wiki/UniqueParticleAttribution.

The three solutions we’ve identified (so far) are:

(1) Remove the explicit references to modules.

The rationale for this approach is that the modules are allowed via the wild-card; hence the explicit reference to a module is not needed. Removing the explicit references therefore resolves the potential ambiguity.

This solution is currently implemented in the schema because the UPA error condition was interfering with development. This was a pragmatic solution to the immediate problem, not intended to suggest this is the only way to address the issue. So the schema currently differs syntactically from the specification, although it neither allows nor prohibits anything differently from the spec.

One key limitation of this solution is that the order of module elements within the wild-card token cannot be enforced through the schema. The specification would need modification to describe the preferred order of module elements, or to define constraints.

(2) Rearrange elements so that at least one required element occurs between the module elements and the wild-card.

Any required element between the module elements and the wild-card resolves the ambiguity. The schema token for a module element in an XLIFF document can be determined unambiguously based on whether it occurs before or after the required element.

<unit>:

The only required token is the <segment> or <ignorable> choice. This would be moved to precede the wild-card.

We may also want to move <notes> and <originalData> to follow the choice group, as they do now.

<group>:

The only required token is the <unit> or <group> choice. This would be moved to precede the wild-card.

We may also want to move <notes> to follow the choice group, as it does now.

<mtc:match>:

Both <source> and <target> are required, and either could be placed between <mda:metadata> and the wild-card. Presumably we'd want to keep these two elements together.

In each case, the optional elements from XLIFF modules would precede core elements, possibly being the first allowed elements in each of the affected contexts.

(3) Define a container element around either module elements or the wild-card.

A container element for either the set of modules or the wild-card would also resolve the ambiguity. The schema token for a module element is determined based on whether it occurs within the container element.

In the case of modules, we would need multiple container types because <unit>, <group>, and <mtc:match> each allow a different set of modules. A container for the wild-card would apply to any point in the model, and so would be simpler.

If we choose this solution, we need suggestions for a name for the container element.

One additional possibility is to rewrite the schemas in RelaxNG. It appears that the existing sequence of module elements and a wild-card can be defined in a way that avoids the UPA issue altogether.

I haven't tried this; I'm not sure how much effort would be involved, nor what other issues we might encounter. But if there's consensus that the solutions proposed above are not acceptable, I can begin work on rewriting the schema.

Thanks,

Tom

Tom Comerford
tom@supratext.com

+1 856 787 9090

Supratext LLC
43 Michaelson Drive
Mount Laurel, NJ 08054

xliff message