- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 03 Jul 2013 23:17:59 +0200
- To: Marc van Grootel <marc.van.grootel@gmail.com>
- CC: public-i18n-its-ig@w3.org
Hi Marc, sorry, some lengthy explanations below and a suggestion at the end. Am 03.07.13 14:17, schrieb Marc van Grootel: > Hi, > > I was working on some XSLT that adds ITS markup to an XML and was > wondering on how to explicitly add ID's that other generic XSLT can > pick up to process (e.g. a generic XML+ITS to XLIFF conversion step). > > In my case I'm not using the full power of ITS rules but rather use it > to make localization information explicit available on the elements. > The XSLT contains the rules in the form of templates. It will add > @its:translate to the translatable elements. > > Now when I look at how to provide an ID that a next step can pick up I > believe the spec wants me to add an @xml:id (8.14.2) That is one way of making the ID information explicit, and, as you said, the preferrable way. See also the related test in the implementation report for ITS 2.0 http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20-implementation-report.html#t-idvalue2xml and the statement in the spec http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#idvalue-local Think of this as CSS: you have two ways of providing a certain type of style style attribute (= ITS local, in your case xml:id) <span style="color:red;"> style element (= ITS global, in your case it would be the idValueRule) <style...> span {color: red;} </style> > > Because I like to separate the processing that does the ITS annotation > from the XLIFF preparation as much as possible this @xml:id in my > opinion breaks this separation. A generic post processing step cannot > simply throw out all ITS namespaced stuff to get back the original XML. Correct. This is like in the CSS case: when a browser has set the color of a "span" element, it doesn't know anymore whether that was accomplished via a style element or attribute. > In case of added xml:id attributes it has no way of knowing if this > wasn't already present in the original or if it was added by the ITS > annotation step. > > I always thought that this was valid use case of ITS. That you could > have an XML+ITS document where all ITS information is made explicit on > the elements itself and no ITS related processing (like rule > interpretation via its:idValue) was needed to use it. Hence I rather > expected to see an @its:id to provide localization IDs. For ITS data categories that provide local markup you can choose to use only local markup and then do the roundtripping you describe. For data categories like ID Value I would argue that there is a good reason not to have local markup: ITS aims at being as less invasive as possible. So inventing a local "its:id" attribute instead of xml:id would break that approach, and put a burden on non ITS, generic XML tools that understand xml:id or HTML id. E.g. if you would have @its:id there would need to be an additional step for viewing HTML content in the browser. With re-using HTML id in ITS 2.0, that is not needed. > > I haven't thought this through for other ITS datacategories and rules > but for simple stuff such as @its:translate, @its:locNote etc.. I can > work like that but not for IDs. You want to identify the step in which Id information has been added, right? ITS tool annotation http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#its-tool-annotation could help here: <p its:annotatorsRef="id-value|myTool" xml:id="p1">...</p> Of course this is more markup than one its:id attribute. But it has the advantage that you can both fulfil your scenario (= strip ITS 2.0 markup out) and re-use existing markup (= xml:id). Hope that helps, Felix > > Any thoughts? > > -- > --Marc
Received on Wednesday, 3 July 2013 21:18:28 UTC