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)

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

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

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.

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.

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

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

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

--f) non-core IDs...

No idea how to address that yet.


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