[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
Thanks Fredrick for the productive feedback. Since the id is specifically intended to refer to the <mrk> element, we should at least introduce a type attribute
then. Additionally, it would still be worthwhile in our opinion to be able to group <notes> with associated note “metadata” as you call it. Any thoughts on that? Perhaps a grouping element or a group attribute a la the discussion on metadata? <notes> <note id=”1” type=“instruction">Do not localize the product name</note> </notegroup> </notes> versus <notes> </notes> Thanks, Ryan From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Estreen, Fredrik 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]