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