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] Fragment Identification

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.


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]