[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] id scopes again
Yves, it was not a double-ferret :-)
While I do believe that we need constraints forbidding cross referencing among units, groups, and files, the fragid mechanism is not confined to being used within an XLIFF file.
Absolute uris can be used e.g. from an online qa system or similar. Groups lacking ids would prevent or complicate beyond reasonable complexity such external referencing.
The same holds for note ids, you‘d be forcing an external system that is not necessarily an XLIFF agent to add XLIFF ids..
As I explained before, my opinion is not so strong in case of notes as in case of groups; these are after all the last referencable items, so it is not so complicated to handle..
Anyway if we stick with optional ids anywhere, we should at least add the caveats (non-normative warnings) that (external) referencing won‘t be possible w/o modifying/enriching the XLIFF file in case of omitted optional ids.
IMHO, there is no benefit in forcing external referencers to become XLIFF agents capable of adding XLIFF ids to its various uniqueness scopes..
Cheers
dF
dF is AFK, so that this had to be typed on his tough phone..
Call me at +353860222158 if this answer does not seem sufficient ;)
Hi David,
> I believe that we have now an issue with optional ids
> on groups and notes or at least on groups.
We can certainly re-visit that: Our discussion on that was before the Fragment Identifiers issue came up.
> Does not seem a big issue, because if you need to reference
> a note you simply assign an id to it and you can reference it, right?
> Not really, actually the referencing will still fail if the note
> is on a group without an id.
No, it won't fail. The only place you use a URI to point to a note is in a comment annotation.
And according the constraint you added since csp02 such reference can only point to a note within the same unit.
Old text:
"ref - When used in a comment annotation, the value is referring to a <note> element."
New text:
"ref - When used in a comment annotation, the value is referring to a <note> element within the same enclosing <unit>."
In other words: you point to that note using simply: ref='n=idOfMyNewNote'.
> However, now you are forcing a simple enricher that was just supposed
> to ad prose comments in a simplest possible way to check for existence
> of ids on parent group elements and ...
The tool only needs to check the IDs of the notes existing in that <unit> to be sure to not have a duplicated value. Or it can use a
UUID and doesn't even need to check anything.
...Or are you saying now that a comment can point to a note outside the unit?
That would be what the US politicians would call a "flip-flop" and British journalists a "reverse ferret". And there is nothing
wrong with that: one can change his mind.
> Now the same complication is repeated for every
> module that has elements allowed on group.
> Therefore I strongly recommend that id on group is made REQUIRED.
We saw that the note argument doesn't hold. But, overall from the viewpoint of implementing the fragment identifier mechanism, it is
indeed rather annoying to have to check for group id. In the light of with that argument, I think it would be OK to have required id
on groups.
> Further, I believe that also note ids should be required.
> If note ids remain optional, I would at least add a Warning on the note
> element and in the fragid section that agents might need to add note
> ids in case they want to reference them.
Terminal parts of the URI fragments (notes, segment, ignorable, etc.) are much less problematic than container parts (like group)
with regard to not having ids: you need ids only if you point to them.
You say "I believe". But what is the rational to have required id on <note>?
For instance, an <item> of the Change Tracking module can point to a note id, but can it point outside the unit where it resides?
I'm not quite understanding the definition: "The value of the ref attribute MUST be the value of the id attribute of a single
instance of an element that is a multiple instance within the enclosing element."
Cheers,
-yves
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]