Profiles notes

[Arle Lommel <alommel@gala-global.org>]

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