RE: [xliff] IDs - uniqueness for inline only within segments (A)

["Tom Comerford" <tom@supratext.com>]

Yves, thanks for your response. So I understand now about the issue of
moving <file> elements between XLIFF documents. I do believe it would be
possible to prevent ID conflicts, without the need for GUIDs, through
contextual qualification of IDs per <file> element. This would be an
additional detail for developers to contend with, which of course would be
one reason to disfavor it.

I also agree for now that IDs within <target> would have to remain as
NMTOKEN attributes.

Nothing I've said should be taken as advocacy; I just need to understand the
broader issues. Thanks for your help.

Tom


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On
Behalf Of Yves Savourel
Sent: Wednesday, October 23, 2013 04:58 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] IDs - uniqueness for inline only within segments (A)

Hi Tom,

Thanks for the well thought points.

One of the main reason why can't use simple xs:ID values is because one can
move <file> elements into different documents. So you could end up having ID
clash after grouping the <files> elements of several documents into a single
one for example.

So the only way we could use xs:ID for the id attribute type would be to use
globally unique IDs. That would fit the constraints of xs:ID, and that would
allow manipulating the <file> any way we want too. But using GUIDs comes
with problems too:

As you noted, the problem with xs:ID would then be that you obviously cannot
have them both in <source> and <target>. Your solution then would be to use
xs:IDREF in the <target>. But then you can have extra inline elements in
target, so those won't point to anything in <source> and can't be IDREFs.

In addition, we do a lot of things with inline codes IDs (outside of XLIFF),
and GUIDs are not helpful in many cases. For example.
When leveraging from a TM the IDs are used to map the inline code of new
source to the inline codes of the old translation. GUIDs will prevent that.

And just from a usability viewpoint: GUIDs are going to look like this:
id="550e8400-e29b-41d4-a716-446655440000". Doing any kind of inline code
manipulation or reading error reports will quickly become very hard for
humans. I don't want to imagine the mess in a XLIFF document with an RTF
layer. The simpler the inline codes are the better.

Another challenge: how would we validate that the id values are true GUIDs?

In short: I'm not against xs:ID, but to use that type the values would have
to be GUIDs, and, in my opinion, it is not truly practical.

I think, while it'd be nice to use XML's at its fullest, we have to remember
that XLIFF is just a serialization of objects not necessarily meant to be
used with XML tools. We shouldn't try to force data like ID values to an XML
specific kind because it's more convenient.

Cheers,
-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php