RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

>> because changing to this only:
>>
>> urn:oasis:names:tc:xliff:document:2.0
>> urn:oasis:names:tc:xliff:matches:2.1
>> urn:oasis:names:tc:xliff:glossary:2.0
>> would be completely confusing for a specification labeled 2.1.
>
> I think that this would not be confusing at all, 
> it would show people that the schema for core and a 
> number of modules did not change since the last version.

Let me get this straight:

In the 2.0 specification we have all schemas with a :2.0 version.
Then, for the 2.1 specification we make a modification to the Matches schema which becomes 2.1, we modify the core schema to use
that new 2.1 Matches schema, and according what you said above, we do not change the URI of the core schema. So now we have two
different schemas for the core with the same URI. That doesn't seem like a good idea to me.

I think that with the current system anytime we touch anything we have to change the core schema (and therefore its URI). That means
the tools have to change too.

Now, let's forget about the issue above and imagine that we're ok with it.
The second issue: I'm not sure how the URIs are related to the specifications. We'll have to check with OASIS and
http://tools.ietf.org/html/rfc3121. It seems there is a document id in the URI pattern and maybe it needs to match the version of
the specification.
I think I'm wrong, but it's something we'll have to verify.

But, let's continue, assuming the two problems above are not issues.

Following the system you propose David let's go through a little set of changes:

We have specification 2.0:
xliff:version="2.0"
urn:oasis:names:tc:xliff:document:2.0
urn:oasis:names:tc:xliff:matches:2.0
urn:oasis:names:tc:xliff:glossary:2.0
 
Then, with a minor change in Matches we get specification 2.1:
xliff:version="2.0"
urn:oasis:names:tc:xliff:document:2.0
urn:oasis:names:tc:xliff:matches:2.1
urn:oasis:names:tc:xliff:glossary:2.0

Then a necessary but backward compatible change in the core specification 2.2:
xliff:version="2.2"
urn:oasis:names:tc:xliff:document:2.2
urn:oasis:names:tc:xliff:matches:2.1
urn:oasis:names:tc:xliff:glossary:2.0

Then another minor change is made to Matches, specification 2.3:
xliff:version="2.2"
urn:oasis:names:tc:xliff:document:2.2
urn:oasis:names:tc:xliff:matches:2.3
urn:oasis:names:tc:xliff:glossary:2.0

Finally a new module is added and we have specification 2.4:
xliff:version="2.2"
urn:oasis:names:tc:xliff:document:2.2
urn:oasis:names:tc:xliff:matches:2.3
urn:oasis:names:tc:xliff:glossary:2.0
urn:oasis:names:tc:xliff:newmodule:2.4

I think many will find the resulting URIs quite confusing.
But regardless...

First: How do you know which specification the document follows?

Second: You have to follow a fixed set of versions, which means tools using older ones cannot participate, even if their
contribution has nothing to do with the new part that has changed.

For example. A document is generated from an extractor with:

xliff:version="2.2"
urn:oasis:names:tc:xliff:document:2.2
urn:oasis:names:tc:xliff:glossary:2.0

Tool_1 adds entries for urn:oasis:names:tc:xliff:newmodule:2.4. that's OK because all current parts of the documents are valid in
spec 2.4 when urn:oasis:names:tc:xliff:newmodule:2.4 was introduced.

Now, Tool_2 is a second tool in the process and it does some TM leveraging. It knows only how to create
urn:oasis:names:tc:xliff:matches:2.1 entries.
But, wait, it cannot do this: it's a document following spec 2.4 since there is urn:oasis:names:tc:xliff:newmodule:2.4 entries.
Darn, Tool_2 can't add 2.1 matches, even if it know all about core 2.2 and don't care at all about
urn:oasis:names:tc:xliff:newmodule:2.4 entries.

So:

- Tool_1 assumed the document was spec 2.4 because nothing in the document said otherwise. But note that it could be a document
build from other spec versions too.

- Tool_2, a spec-2.2 tool, could not do its job even if the extractor was possibly following spec 2.2 not 2.4.

- The merger (presumably following the same spec as the extractor) may be a spec 2.2 tool and may not be able to process the
spec-2.4 file coming back: but we can't know that until the merge occurs.

- And during all that time, each tool had to look up all module URIs in the document to try to guess what the specification this
document corresponds to.


Now you'll tell me: Easy fix: the xliff:version attribute should hold the spec version, not the core version.

OK, so we'll end up with a core attribute version="2.4" when the core is actually version 2.2. But at this point we can probably
live with that weirdness. (if we go that way I'd suggest to change the name to specVersion to make things less confusing).

So now we have less difficulties to know what spec a given document should follow.

But we still have the completely artificial limitations that a given module should be of a fixed version just because the document
is marked as following a given specification. And all that because our single specification is bound to fixed versions for the core
and modules.

Again: that is not modularity for me. You could do exactly the same with a single namespace with optional elements/attributes (and
that would be a lot less confusing).

XLIFF modules should be able to live independently from the core and each other as long as they are 2.x.

A tool will have to upgrade its support for all changed modules when it wants to upgrade one. It's totally unnecessary and
counter-productive. There are no reason why a document could not have, following the example above,
urn:oasis:names:tc:xliff:matches:2.1 and urn:oasis:names:tc:xliff:newmodule:2.4 at the same time: They are completely separate
modules.

The problems keep piling up. One spec and multiple namespaces just doesn't really work for modularity.



>> But I know going from 2.x to 2.y at each module change is 
>> not viable either.
>
> The modules have been in appendices and they are now in their own section,
> they are optional still the TC decide to have them in one spec that 
> fulfills a number of approved business requirements. 

All that is very nice. But it just doesn't work.



>> I think I've addressed that with the suggestion of
>> changing the PR to preserve the elements based on 
>> the start of the namespace URI.
>
> I do not understand how this is supposed to work. the modules 
> won't be explicitly included in our schema, so tool would be 
> requested to know ad hoc about other namespaces that are 
> not in the schema?

I don't understand what you don't understand :)
The tool just check the start of the namespace and can see if it's an XLIFF TC namespace or not: no need to involve schema for this.
Even core-only processors can do this.



> But we had a discussion saying that also 
> w3c or similar namespaces would be OK, than we would 
> need to anyway continue maintaining an exception 
> list outside schema, I do not think this is practical.. 

Well currently such namespaces can get nuked. 
Do we actually have a resolution recording those exceptions?
If we do then there should be a PR in this version of the core for this. And if a PR in the spec, then the tool could look for those
URI (or start of URIs) as well.



> I think we have modularity, certainly more of it than
> in 1.2 certainly less than ITS 2.0 but that would not 
> be a fair comparison.
> Our modularity in case of solution 2 would still be 
> better than DITA specializations.

Not sure what ITS or DITA have to do with XLIFF, but what we have is a better specialization of the elements than in 1.2: they are
groups by types of functionalities.
But that is not being modular.



>> I don't think the community would like it very much when 
>> they realize all tools have to be changed each time a 
>> module is added, removed or modified.
>
> I think that this is true only if you accept that namespace 
> URN have to be changed even if the schemas did not change. 

Yes, and that is always true.


Cheers,
-yves