Re: [xliff-promotion] Profiles notes

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

Thanks Arle, this is indeed a good start of discussion; and since no one has taken it it up to now, I'd say that core is core and therefore "atomic" from the point of view of profiling, thus not be further subsetted.

I am however not dogmatic about that and would be willing to revisit with specifics if we went for a very large core (as some of the corporations might want to push).

Still, I like your analysis of pros and cons and I think that the proper way of dealing with cons is actually leading towards saying that core must not be subsetted.

Since, what does it mean subset? It is perfectly OK a specialized tool only modifies elements that it makes use of. And I would say it is also OK to ignore them and pass on unharmed if they are irrelevant to a given transform.

Passing all core elements and attributes unharmed should be the other bottom line principle that I had in mind in SC but could not recollect.

Assuming, for the sake of the argument, that inline codes are in core; I should like our profiling policy to prevent selectively supporting only some inlines.

They might develop some advanced handling for some of them that however does not break the cycle with tools who do not have it.

But here even leaving unharmed should not be OK, all inlines would need to be read and displayed as inlines, in such a case, fulfilling at least minimum processing requirements if they are to be modified either in source or target.

Rgds

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 Tue, Feb 21, 2012 at 18:43, Arle Lommel <alommel@gala-global.org> wrote:

Hi David,

I have one key question about profiles that I think we need to address before anything else: Can profiles be subsets of the core?

This issue came up in the discussion of IN’s xliff:doc format. Can an XLIFF profile be more restrictive than the core XLIFF or must it be open to all core features? Being more restrictive would promote interoperability with tools that use the format and (in a one-way fashion) with any tools that use a less-restrictive subset of XLIFF. It would impede interoperability when moving from a less restrictive subset to a more restrictive one. I’d like to see more details on where xliff:doc fails at present, but David, if I understood correctly, part of your issue was that it doesn't allow all valid XLIFF files to be used. Can you elaborate just so I am sure I am working on the same basis you are?

Note that I don't know that there is a philosophically “right” answer to this question. I'd be in favor of allowing subsetting, but I can see where others would object. Unless I've missed the decision about this point, I do think it should be discussed in terms of the pros and cons. For the record, I see the following:

PROS:

• Restricted subsets can improve interoperability between tools sharing the same profile.
• Processing a restricted subset would simplify development of special-purpose tools.

CONS:

• Allowing restricted subsets would make it so that XLIFF is not always XLIFF from the user perspective: someone can receive a perfectly valid XLIFF file and not be able to use it.

I think there are ways to address the con given above: (1) mandate that any tool using a subset profile pass core features it doesn't implement along; (2) mandate that tools that implement only a subset NOT claim to implement XLIFF, but rather the named subset.

Profiles that are supersets of the core (i.e., they are core+module construction) obviously aren't a problem as long as we mandate (which we have done) that the modules cannot usurp any functionality from the code, i.e., abusing the structure to get around something in the core that someone doesn't like is definitely verboten.

Those are my initial thoughts. I have other ones kicking around, but this seems to be a core issue that would need to be resolved before addressing most other points.

Best,

Arle