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.*

Background:
----------------
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 -
https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201303/msg00005.html).
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
https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201303/msg00016.html
It was also discussed after inline SC conclusion:
https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201303/msg00017.html
and several other occasions..

Thanks for your attention
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: