[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (notes)
>> On the other hand having a minimum set for interoperability for ITS unaware tools sounds good.
Agreed. And as stated on another thread…we suggest the list of additional and optional attributes to be origin, category, datetime.
<note category=”instruction” origin=”developer” datetime=”2012-11-30T07:43:05Z”>Don’t localize Windows</note>
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Dr. David Filip
Thanks for outlining the options, Fredrik,
I would be personally OK with note being just extensible.
The ITS categories would allow to specify pretty much everything that you would need. First as extension, that should later turn into a module using the same mechanism.
On the other hand having a miniumum set for interoprability for ITS unaware tools sounds good. And as Fredrik pointed out ITS note can be easily mapped on these, so not an issue from here.
Even with the minimum set of core attributes, I still think it should be extensible.. to allow for unforeseen types of annotations..
The only danger is of creating unnecessary clutter if the adoption is minimal.. hard to say what the adoption will be..
Dr. David Filip
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Thu, Nov 29, 2012 at 10:39 AM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:
Hi Ryan, David,
How it would look is dependent on if we add one or more standard attributes to the <note> element or rely solely on third party extensions. First an examples of one of the notes in your original sample and one showing a potential use of David’s ITS mapping case.
<note id=”n1” ms:noteOrigin=”developer” ms:notePriority=”1” ms:noteType=”comment”> This string cannot be longer than 100 characters</note>
<note id=”n2” its:locNoteType=”alert”>Make sure to adapt date format when localizing</note>
It could be argued that there is a set of very common metadata associated with notes and that we should provide standard attributes in these cases. I’m not sure exactly which, if any, we should have but the ones I can immediately think of are the kind of information in the above sample plus a date:
* origin / author – Indicate source of the note
* priority – indicate relative importance of a note. Must have strict simple definition. Integer lower is more important than higher for example.
* type / category – indicate what type / aspect of the data or process the note applies to or annotates.
* date – creation or modification date. Which of these it is should be specified.
The good thing about using standard attributes instead of extensions for common properties is of course better interoperability for the data contained. The negative side is that it adds complexity to the standard which is against one of the goals of the 2.0 work. One part of that is the attempt to reduce the number of seldom or never used constructs to get a leaner core model. A solution that has been discussed before is to have a more complex comment / annotation module in addition to or extending the core feature. This way we get the same complexity in the core as we would with just third party extensions but with the added value of a fully interoperable path for those that want that in this area.
If we hypothetically assume we add origin and priority to the core the above example could look like the bellow. Assuming the same mapping for ITS is used as the one proposed for mapping to XLIFF 1.2 (‘alert’=>1, ‘description’=> 2+) and stored in “priority”.
<note id=”n1” author=”developer” priority=”1” ms:noteType=”comment”> This string cannot be longer than 100 characters</note>
<note id=”n2” priority=”1” >Make sure to adapt date format when localizing</note>
Regarding the naming of potential core / module attributes I would prefer to use “category” instead of “type” as the former does not convey the level of functional meaning that the later does for me. It is more ‘just metadata’.