OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Electronic Ballot Proposal: Markers Extensibility

Dear all, this is to formally propose to make <mrk> and <sm> inline
elements extensible by custom namespace *attributes*.
This should be a simple yes/no/abstain ballot.
The change of spec and schema is fairly simple, just allowing
attributes from any namespace on <mrk> and <sm>. Extensions on mrk
will be governed by the general processing requirement that they
SHOULD be preserved IF they are not processed as per their own PRs.

*Looking for a second.*

Markers (<mrk> and <sm>) are part of the XLIFF annotation mechanism.
Annotation needs that we currently do not foresee, can appear, and I
believe that the markers should be extensible to allow for emergence
of specific annotation modules.

The current set of marker attributes w/o extensibility e.g. does not
cover the use case where several ITS categories need more than one
attribute to properly represent all metadata items pertaining to a
sub-segment span of text.
Please note that <Note> that is the structural element for handling
annotations was made extensible by a recent group consensus (Feb 19 -
Also please note that this is just for *custom attributes on markers*.
This does NOT violate the F2F consensus that no custom *elements* be
allowed inline.
This was last discussed in the conference call on March 5
It was also discussed after inline SC conclusion:
and several other occasions..

Thanks for your attention

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]