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

["Dr. David Filip" <David.Filip@ul.ie>]

Yves, only a few short answers inline, as we are beginning to go in circles..
dF

Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie


On Fri, Oct 26, 2012 at 12:15 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
> 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.

1 thing we agree on in this thread
>
> 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.
>
I agree that PRs do the trick, I just do not want them to protect
extensions as it would undermine the whole idea of normative modules.

>> 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.
>
Going for the short names might make sense, I am getting exactly this
feedback from MT producers. The reason why I was not pushing this is
that I am also concerned with human readability. We might want to
discuss it separately whether or not we care

But you are avoiding the argument here.
The extension can be anything and you want to force innocent people to
preserve it no matter what. Do I need to accept it if it makes the
file ten times bigger? Do I need to accept it if I am able to tell
that it is neither core nor module?
>
>> 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.

Yes, and they should only protect modules, not extensions
>
> 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?

It seems clear to me that full new version must be published every
time (a number of) module(s) is added. But these will be minor
versions (2.x) that do not break backward compatibility of core or
modules.

> - how extension ABC that existed in 2013 suddenly becomes non-compliant because it does the same thing as module XYZ defined in 2014?

Surely this extension will become illegal. If the owner of the
extension had enough sense, she took part in specifying the module
that made it obsolete, so that her needs are catered for by the
module.

> - can we add module elements/attribute in core elements where extensions are forbidden if we need to?

Do not understand this one, can you elaborate?

> - 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.

OK I am not talking about deleting extensions in skeletons, skeleton
is so underspecified that extensions must be protected in skeleton, I
agree, and I did not reflect that in the previous strawman.

There is a general problem with metadata support on segments due to
re-segmenting. We might need to look into detailed ways to maximize
metadata survival on resegmenting. But again I do not want to protect
extensions.
>
>
>> The general Processing Requirements should go like this
>> Core MUST be processed.
>> Module MUST be processed if supported, or otherwise preserved.

[Inserting skeleton provision]
Skeleton (if present) MUST be preserved including extensions until re-merge.
[Modifying due to the skeleton provision]
Extensions outside skeleton MAY be processed, preserved, or deleted.

>> Extensions outside  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.

So you would be OK with deleting modules?

How do you know a module is a module if you don't support it?

I do not need to support it to know it as a module

>And even if you do know, why make a distinction?

Because extensions are not part of the spec and can be anything.

> If you can preserve a module you don't support can also preserve a custom namespace exactly the same > way.
I have the option to preserve, I do not want my option to delete it to
ber taken away. I will opt to preserve and even process its: and
related okp: and dc: etc. extensions even before they will become a
part of an officially approved OASIS XLIFF modlule, becuase the
authorities behind the related specs and namespace are good enough for
me.

> Why encourage to break people's processes?

Because guaranteeing the lifecycle for private extensibility will kill
interoperability in the long run. Core is the smallest common
denominator, the plan is to expand the public spec based
interoperability by adding modules. If extensions have the same level
of protection as modules, there will be no incentive to grow the
lowest common denominator.

Extensions are by definition for private use. If TC tries to warrant
their survival it undermines its own merit and kills the idea of
modular standard that can be enhanced with official modules. No one
will strive to specify commonly used modules if their extensions are
protected no matter what.

I MUST preserve a module because it is a part of the OASIS spec, I do
not want to be forced to preserve extensions, as they can be ANYTHING.
I am NOT going to sign a "carte blanche"
>
> Cheers,
> -yves
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org
>