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: Re: [xliff] IDs - Optional attributes (E)

Thanks, Yves, inline

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734

On Tue, Nov 19, 2013 at 1:48 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David, all,

> Thanks, Yves, I think that we are mixing two features here

Not really. It's all about how to resolve a fragment identifier in XLIFF.

Your outline is mostly what I had in mind as well. But with a few differences/issues:

-- a) I would use / to separate the different IDs rather than # which may cause confusion or break implementations looking only at the last # to find a fragment identifier.

would point to the lone unit of the first file

would point to the lone segment of the second file
We discussed this internaly at LRC
/ seems confusing to me, becauase it is not really a directory
using # as separator is OK, as it needs not be escaped..

--b) identifying the file with the value of origin is a problem. It's value is an URI. I'm not sure it's a good idea to have a URI as a part of another URI.
Not nice but should work, the other option is required ids, see furtehr 

This would leave us with having both origin and id for <file>, and having id required. But we would have to make provision for what happened when a Modifier groups <file> in the same document. Maybe it's Ok to have the file ID be a UUID.
I agree, seems the cleanest solution.. 

Another option would be to come up with a non-URI value based on a required origin, like the hash code of the URI string. But that may be adding a lot of complexity.
I agree this adds too much complexity to be worth considering.. 

--c) Group ids vs unit ids. I really dislike having those two completely separate structures share the same value space for their IDs. It may be alas the only solution to address URI fragment resolution.
Yves, I argued for unit ids being only unique within parents and group ids required. If it was so, you would not need the same scope for them.
As it stands, this is, alas :-), indeed the only solution.. 

--d) Segment ids and inline elements Ids: Same here, there is something wrong with those two different levels of structure sharing the same value space for their IDs.
To me this seems to shows that segments should have been a special kind of inline annotations rather than a separate level of structure. It will probably come back to haunt us, but it's too late for such massive change.
I agree that this cannot be changed. This is strictly analogical with the grouping.
Yet, having only two internal id scopes has advatntages, so I am not especially unhappy about unit being a single uniqueness scope..

--d) relative URI (just the fragment) may be difficult to implement. Maybe there are ways to have defaults based on the location of the relative reference. I don't think having a bunch for ref="#f1/g3/note6" is going to be nice when you are working within the same unit. In my case I get a better sense of what's working or not when implementing things.
I think that all internal referencing should be done using just #id. This will be unique within core due to the uniqueness constraints. 

--f) non-core IDs...

No idea how to address that yet.
I believe there are two options, module prefixes as I suggested
or UUIDs as in case of file 


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:

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