[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)
|
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. <notes> <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> </notes> 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”. <notes> <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> </notes> 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’. Regards, Fredrik Estreen From: Ryan King [mailto:ryanki@microsoft.com]
David or Frederick, can you give us an XLIFF example of how that would look? From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip Fredrik, all, same as Fredrik, I think that extensibility makes sense here. I agree that the grouping mechanism in the style of mda is not appropriate here and would change the semantics in an undesired way. Annotations are perfect extension points in general, and besides we need the extensibility here for the its mapping. 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 Wed, Nov 28, 2012 at 10:10 AM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote: Hi Rodolfo, Ryan, I think the intent of the <notes> is lost with the current proposal. The feature is designed so that
<notes> is a container for a group of <note>s at a specific level in the document. Where each <note> is one annotation / comment in itself. The suggested change transforms that so that the <notes> element becomes the entity describing one note, with <note>
describing specific pieces of metadata related to that note. The ID is intended to be used to refer to the note from other places such as from <mrk> elements in the inline content, so overloading it to be the type of data would cause additional problems. I think the initial model is much easier to work with and more clean as it contain all note related
information in one sub tree per document level where notes are allowed. Adding attributes to the <note> element is in my opinion the best way to go. If we should have more standard attributes or if a processor is free to use the third party namespace extension
mechanism to add them is another question. Depending on how simple we want to keep the basic notes feature it could be either or a mix of the two methods. Although I’m not a fan of the third party extensions I think this is a case where they could make
sense. And if used for process specific metadata only I don’t see an issue. Of course there will be no standard way to display them in a UI or report if they are not specified in the standard. Regards, Fredrik Estreen From:
xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Rodolfo M. Raya
Still a bad use case that doesn’t justify ruining a good design. Regards, Rodolfo -- From: Ryan King [mailto:ryanki@microsoft.com]
So that our original reason for proposing having more than one <notes> at the extension point does
not get obfuscated in all of the replies and “see inlines”, here once again, is the use case for adding more than one <notes> per extension: Proposal 4: Add an optional name attribute on <notes> in core and <mds:metadata> module. We believe it will be typical for content providers to want to group their notes or metadata in meaningful ways. This might be done so that a certain number of notes or bits of
metadata can be processed in the same way, or simply grouped and displayed together, such as in an editor UI. Here are some examples: <notes
name="comments"> <note id=”priority”>1</note> </notes> <notes
name="instructions"> <note id=”priority”>2</note> </notes> As opposed to something less structured and more difficult to process: <notes> <note id=“comment">This string cannot be longer than 100 characters</note> Thanks, Ryan From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
Please don't ruin te design for <notes>. Only one should be allowed per insertion point. Regards, Rodolfo
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]