As a newcomer, I am not yet eligible to vote, but this is a chance to start
sharing my views. So here's my position on this ballot:
- It looks like most everyone agrees on the necessity of <sc>/<ec>. So if
<pc> were also included, it would be entirely redundant. Everything that
can be expressed with <pc> can also be expressed with <sc>/<ec>, and <pc>
becomes a "shorthand" for some forms of <sc>/<ec>. I think this is bad
design for several reasons:
- Consider how you would handle this as an implementor. When reading
XLIFF, you would almost certainly map both constructs to the same one
internally. When writing XLIFF, you have two choices: 1) always write
<sc>/<ec>; or 2) figure out when you can use <pc> and use write <pc> in
those cases, otherwise write <sc>/<ec>. Practically, why would anyone
do (2)? The result is everyone writes <sc>/<ec>. <pc> is useless
- Lazy implementors (and they're all lazy) are likely to implement <pc>
right, and <sc>/<ec> sloppily. This is a serious practical problem, and
if you think about the industry's experience with standards, I think
you'll agree that implementors routinely do the easy parts and skip the
hard parts. We're much more likely to get correct implementations if
there is only one way to do it. (And of course we offer good developer
- Imagine a future specification for "XLIFF normalization" (which will be
necessary someday). The obvious thing to do is normalize <pc> to
<sc>/<ec>. So <pc> is just extra work.
- I'm not entirely against shorthands. They are good for human-writable
documents, and for saving space. But I don't think either consideration
- Those who like <pc> for XML seem to agree that <sc>/<ec> are necessary
even for XML, in some cases. So nobody gets to live in a fairy land
without <sc>/<ec>. Why pretend? ;-) Maybe you can go a little way with
just <pc>, but then some day you have a use case that requires <sc>/<ec>.
You'll curse the day you started with <pc>!
- "XML friendliness" has little value for me. XLIFF is designed for
localizing any content, and while we should make sure it works well for
XML, I would be wary of any bias to working "best" with XML. Besides,
there's enough work between us and XLIFF 2.0 that giving special attention
to XML doesn't seem to be a good use of effort.
- (Ok, I can't resist veering into the philosophical.) I don't think
<sc>/<ec> is hackish at all. The right question to ask here is whether
overlapping markup has value in the real world. I think the answer is
obvious. Consider a word processor. They user selects words 1-3 and
presses "bold", then selects words 2-4 and presses "italics". How should
the word processor represent this? Overlapping markup is clearly a
reasonable option, and nested markup starts to look like a hack.
Overlapping markup may not be the common case, but it's not a freak
either. Don't treat it like one!
Some ideas borrowed from Ted Nelson: