RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, Rodolfo, all,

> Same as Rodolfo, I think that it is a substantial 
> difference that XLIFF modules have an OASIS warranted 
> published schema, whereas extensions don't.

I agree, it is an important difference. It allows you to validate or not a vocabulary.

And that's it. A schema doesn't tell me what a tool should or should not do when manipulating the elements/attributes of a namespace it does not know. The processing requirements do that. They dictate what the schema can or cannot do, not the reverse.


> This is also what I mean when I say that support of 
> extensions can be negotiated outside XLIFF TC.
> Some authorities behind namespaces (and underlying semantics!) 
> are better than others, so some people might be happy to 
> validate against a W3C published schema rather than against 
> a schema published by a private initiative or a single tools vendor.
> And why should people bother at all to preserve stuff that has 
> no published schema at all?

I guess we have vastly different expectations.

As an XLIFF user I don't give a hoot if the extension XYZ has a schema or not.
I just want XLIFF to have processing requirements that allow any tool to deal with that extension. And I expect that extension to abide by those processing requirements too.


> Still a Corporate buyer or an LSP can negotiate within their 
> supply chain that their extensions won't be deleted. They might 
> even negotiate that they will be supported, ideally as an OASIS 
> warranted XLIFF module :-)

Sorry but that make no sense to me.

XLIFF must work out of the box, without taking into account negotiation between LSP and tools vendor, or schema provided or not.

The most common use of XLIFF is this one: Tools ABC generates an XLIFF document, the translator use tool XYZ to translate it. There is no relation whatsoever between the two tools. The only thing that can make interoperability works is that both tools adhere to the processing requirements set in the specification.


> Obviously schema is not enough for processing, and sure enough 
> we do not want the core only applications to process the modules,
> we only tell them to preserve them and for that end, schema 
> should be enough.

I'm sorry, but again as an implementer, I don't see how a schema can help me in preserving or not elements/attributes. Making sure an application can store and re-provide non-core markup has nothing to do with validating that same markup.


> On the other hand if someone multiplies the size of an xliff file 
> by inclusion of some verbose proprietary mark up it is totally 
> legitimate to delete it to preserve own storage resources.

If you are worried about size, you should work on having the WG use <seg>, <ign>, <src>, <trg> instead of <segment>, <ignorable>, <source> and <target>. That's where you'll get you best savings.


> Extensions can compete for feature coverage with other extensions,
> but MUST NOT compete with features covered by core AND modules.
> Modules are documented in the same spec as core and other 
> modules, along with a schema that allows to recognize 
> them as protected.

a) Again, schema doesn't allow any optional thing (modules and extensions are always optional) to be "protected". The processing requirements do.

b) How modules are going to be defined after the core is released is a whole different (and important) topic that deserves its own thread.
There are many unknowns we have never talked about yet. For example, I'm still not clear on things like:
- how do we add modules without releasing a new version of XLIFF? or do we?
- how extension ABC that existed in 2013 suddenly becomes non-compliant because it does the same thing as module XYZ defined in 2014?
- can we add module elements/attribute in core elements where extensions are forbidden if we need to?
- etc.


> I believe the following is a substantial question:
> What good can come from preserving an extension if you 
> must not rely on it for merging back?

Extensions can be rely on for merging when they are in the skeleton. I think the problem with extensions placed elsewhere is that they may get deleted depending on the manipulation of the data (re-segmenting, removing <mrk>, etc.


> The general Processing Requirements should go like this
> Core MUST be processed.
> Module MUST be processed if supported, or otherwise preserved.
> Extension MAY be processed, preserved, or deleted. [my preferred way]
> Or we might want to say something like:
> Extensions SHOULD NOT be deleted if their schema is declared 
> in the XLIFF document AND publicly accessible.
> Otherwise Extensions MAY be processed, preserved, or deleted.

Binding what the processing requirements for extensions to the presence or not of a schema make absolutely no sense to me.

Using 'SHOULD NOT' may be ok but there is no reason to make a difference between modules and extensions. How do you know a module is a module if you don't support it? And even if you do know, why make a distinction? If you can preserve a module you don't support can also preserve a custom namespace exactly the same way. Why encourage to break people's processes?

Cheers,
-yves