- From: Marc van Grootel <marc.van.grootel@gmail.com>
- Date: Wed, 3 Jul 2013 14:17:07 +0200
- To: public-i18n-its-ig@w3.org
- Message-ID: <CA+bQNCuwib_fWSrSixkFvSERCfmX9fX5-XH4P=iqJLcesouLWQ@mail.gmail.com>
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) 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. 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. 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. Any thoughts? -- --Marc
Received on Wednesday, 3 July 2013 13:31:25 UTC