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: Re: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements


Yves,

I agree that it would be bad to have a ballot every time two sentences are changed. Yet these sentences are not any two sentences.
My goal is to be able to put together a conformance test suite, which cannot be achieved unless PRs are sorted out throughout the spec. And it is only natural to try and fix the PRs starting with general processing requirements.

Sure enough, there is a contradiction with 2.7.2 but IMHO this contradiction should be simply fixed (with no need for a ballot) by changing 2.7.2. [replace MUST with SHOULD] in case the proposed general principle is approved by the TC ballot..

I formulated the ballot proposal as a proposal about wording as I agree with Rodolfo that at this point, we should have very specific discussions about current draft wording and how to change it to make the spec better and closer to final TC draft.

I believe there will be few more ballots before the bulk of the spec can go for a full ballot resolution

Also I proposed the ballot, as it seems the only way how to figure out the  preference of the TC et large, because so far the only people active in this discussion, are you, Rodolfo and myself, which does not provide much material for consensus sensing.

@All, still looking for a second, eventually for a competing/clarifying wording proposal for the general PRs.

Cheers
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, Nov 2, 2012 at 3:38 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi,

 

David: I don’t think it’s healthy to have to go through a ballot each time we change two sentences.

Especially when the new wording of section 2.1 contradicts the wording of 2.7.2.

 

No matter how you look at it, there is no technical ground to treat custom extensions and un-supported modules differently.

 

Before we resolve whether or not they should be treated differently based on philosophical reasons, we need to define how un-supported elements/attributes should be handled in operations like re-segmentation. Blanket statements are not making sense.

 

Regards,

-yves

 

 

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Thursday, November 01, 2012 3:30 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements

 

Hi,

 

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

preserve.

 

 

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.

 

Regards,

Rodolfo

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.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..

 

BTW,

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

 

Cheers

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

 

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.


Cheers,
-yves


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