Title: RE: [xliff] Fragment Identification
Hi Yves, all,
> > For modules they should define their own two to five character
> > prefix (as David suggested) to be used for references. The prefixes
> > should be registered with the TC to avoid conflicts.
>
> Mmm... the registration aspect is a bit problematic:
> Aside from having to do the registration, there is the issue of how does a tool know which prefix corresponds to which extension? It
> has to somehow keep up with the registry. It's doable but it starts to get very complicated.
>
> I was thinking about using the namespace prefix used for the module/extension in that document. The problem is that such prefix
> could change if the document is re-written.
> Self-declared prefixes would be about the same as using the namespace prefix. With likely less chances to have the prefix be
> modified.
> But, I do not like that non-persistence aspect in both cases.
I agree, both seem problematic. I like the idea of using namespace prefix.
> I also assume the scope of the ids for module/extensions would be the <file>, right?
Yeah, this seems the most logical scope for modules/extensions.
> > That is true, having groups and units share their scope leads
> > to shorter references (as ids on groups are irrelevant since the
> > units are guarenteed to be unique within the given file).
> > On the other hand, you must ensure each unit in a given file
> > has a unique id for all groups in that file.
> > What are your objections to this?
>
> Groups and units are different classes of objects, there is no reason in a CAT/TMS tool that they share a unique ID space. Keeping
> them separate in XLIFF allows the tools to have either cases internally.
>
> I don't think having shorter URI Fragment identifiers in XLIFF (just an exchange format) is a good enough reason to foist such
> constraints upon the tools. This could lead to tools starting to use extensions to carry their real ids.
>
> The fragment identifiers issue can be resolved without that change, so to me the question is more: what is the justification for
> such a change?
As I see it the only reason to have ids on group elements would be to reconstruct the grouping after processing. In that case each group would be required to have a unique id. However, that seems like a processing requirement so maybe its not in scope. That said, if it can be resolved without requiring a change maybe it would be best to leave the scopes as they are.
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
