[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
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 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 -- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip 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 mailto: david.filip@ul.ie On Sun, Oct 28, 2012 at 11:14 AM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi David,
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]