OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

sending from the proper e-mail address..

---------- Forwarded message ----------
From: "David Filip" <davidf@davidf.org>
Date: Nov 2, 2012 2:31 AM
Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>
Cc: <xliff@lists.oasis-open.org>

Thanks Rodolfo, this wording indeed covers my requests.
As I believe that this is a matter of high importance and profound impact, I'd like to propose an electronic ballot to approve this wording. Hereby proposing and looking for a second.

The ballot is intended as a yes/no ballot about Rodolfo's entire wording of the general processing requirements based on my 2 change requests.

This ballot is not intended as a ballot about the previous wording of the section. If this ballot does not pass I'd say that the section is unstable and requires discussion in TC at large.
Thanks and regards

On Nov 1, 2012 9:29 AM, "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote:



In latest published version of the specification document I modified the general processing expectations (section 2.1) to this:



• A tool processing a valid XLIFF document that contains XLIFF-defined elements that it cannot handle

must preserve those elements.

• A tool processing a valid XLIFF document that contains custom elements that it cannot handle should

preserve those elements.

• When a <target> child is added to a <segment> element, the value of its xml:space attribute

must set to preserve if the xml:space attribute of the sibling <source> element is set to




The change covers one request from David regarding spaces and separates the treatment of extensions and XLIFF elements.


This is just a starting point, please propose a new concrete wording if you want changes.


I think it is time to change the format of our discussions. Everyone should read the specification and propose concrete changes to the text wherever it is necessary. We should move from generalizations to detailed pieces of text.




Rodolfo M. Raya       rmraya@maxprograms.com


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Wednesday, October 31, 2012 11:45 PM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements


Yves, I think we are getting closer.

@All I'd like to see more opinions regarding this issue, I believe it is crucial..


@Yves, you are right that my reasons to allow deletion of extensions are not technical to a large extent.

[my reasons can be prioritized as follows:

1. general standardization principles (why should the TC sign a "carte blanche" for any extension producers),

2. underpinning the importance of TC approved modules in the standard's architecture (closely intertwined with reason 1.).

3. technical issues like storage size of verbose markup, constraints on number of namespaces in generic XML tools]


I guess my approach to extensions making it to modules is naked Darwinism. If someone produces extensions that others take the trouble to track down and delete, they will probably have trouble to make it to an official module.

1.2 does not have processing requirements so I guess it is admissible to delete extensions, as you will not produce an invalid XLIFF file by just deleting extensions. Still some extensions are getting support among third party implementers for whatever reasons, as our survey showed.


Same as you, I would be unhappy with TC approving member submissions for modules without proper vetting. But I would not be too afraid of that, as [as explained in the last round, the nature of our standard will force us to re-publish the whole spec each time for minor 2.x versions, that is whenever a module or batch of modules is added] there will always be a full blown committee and OASIS process whenever adding them.


I am happy with saying that extensions SHOULD NOT be deleted (without further qualifications), rather than making the deletion or not truly optional (MAY).

Still I do not see why modules should not be unconditionally protected. As we know what is in modules, we can vouch for them and we absolutely do not want to undermine them by letting users to decide if they might need to delete them. 


Valid behaviors that core only implementers can adopt are practically two:


1) Process core and preserve everything that is on extension points (modules or extensions).


2) Process core AND validate the whole document against all official XLIFF schemas. Eventually, cut parts of the tree that are NOT protected AND causing them trouble (i.e. if they have valid reasons not to follow the SHOULD).


Most of the implementers probably won't bother to track down AND delete the unprotected parts UNLESS these are causing bigger trouble by being there.


This seems exactly the intended behavior to me..



I discussed the general behavior of extensions in XML based standards with Jirka Kosek today [took advantage of him being at W3C TPAC].


He said that it is best practice to preserve extensions that have attribute mustUnderstand set to 'yes'. The rationale of having such attribute is to indicate whether or not an extension changed the semantics of the core, so that it does not make sense without the extension. IMHO we implicitly prohibit such behavior of extensions, although I believe there are such extensions on 1.2 [bad]. We might want to be more specific and prohibit this explicitly. IMHO it follows from prohibiting to rely on extensions for the roundtrip, still being more explicit cannot hurt I guess.


Generally Jirka would see no harm in deleting extensions in XML formats except the above exception that we can safely rule out for XLIFF, moreover he pointed out that it might be better to delete them, then eventually to create an ungrounded suspicion that the extension actually was understood and processed.


Mark you, that this argument cannot be turned against preserving modules, because implementers MUST use modules (and not extensions) if they have functionality covered by modules, so if they do not do anything to modules it follows that the modules are always in the right state from the last tool that made use of them. .


As I said before I would be happy to protect extensions in skeleton that is underspecified, so that we basically encourage the implementers to use magic in skeleton, if they are using it at all..





Dr. David Filip



University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

On Sun, Oct 28, 2012 at 11:14 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David,

I see that your main argument is not a technical one: We should encourage people to treat custom extensions as second class citizens because they undermine the idea of normative modules.

But I think this is the wrong way to look at it:

Extensions do not undermine the whole idea of normative modules. They are part of the whole idea. Official modules are not going to be just appear out of thin air. They'll start as extensions, get tested, be improved, as they are used as extensions. Then they'll migrate to become official.

I don't think it would be good to see company XYZ come to the TC and say: "Here is a proposal for a module." And have the TC (which has very little bandwidth), have a quickly look at it and say "OK, let's add it". We need real feedback, real implementations, real users looking at and using the module. And the most natural way to have all that is through extensions.

In order to have such evolution, they need to have the same processing requirements as a module.

Some extensions may end up becoming modules without even changing their namespaces, as we want to promote re-use and interoperability. Parts of ITS are possible examples of this.

I'm OK with "SHOULD NOT be deleted" rather than a "MUST be preserved" (the 'must' come from the discussion the TC had not directly from me). But, regardless what the processing requirements end up being, they must apply to both modules and extensions. Otherwise XLIFF is detrimental to users who want to make their needs/solutions evolve into official modules.

Sure, not all extensions will become modules, but we can't control that. What we can control is the basic behavior that all tools should have when manipulating elements/attributes of namespaces they don't know.


To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]