[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
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]