RE: [xliff] RE: fragid in mtc

[Yves Savourel <ysavourel@enlaso.com>]

Thanks Bryan,

We should try to enhance the explanation in that section as soon as possible then.
Maybe the best way is to provide a couple of examples, like an internal and an external reference.
I can try to do this asap.

My worry is that if it's too hard to implement with XSLT we should be aware of it rather sooner than later. You may run into issue I
didn't run into with Java.

Cheers,
-ys

-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] 
Sent: Wednesday, January 15, 2014 6:15 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: fragid in mtc

> I really would like to see more than one implementation, especially 
> with a language like XSLT. Any plan for that Bryan?

Yes. As soon as the dust settles I will read the "Fragment Identification" section. If I can understand what it says, I will (try
to) implement this.

If I cannot understand it well enough, I will recommend enhancing the section to make it more understandable. Reading between the
lines you might detect that I don't think there's enough information in that section as it is now for me to know how to implement it
(an example might be useful).

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, January 15, 2014 3:30 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: fragid in mtc

Hi David, all,

>> The more general solution to make all extension/module be potential 
>> container rather than terminal sounds better, but it look very hard 
>> to implement (nested extension/modules like mda in mtc here).
>
> I think that the general solution would be to say that modules and 
> extensions are allowed to reuse core and mda and IF and only IF they 
> do so, they are no longer terminal but can act potentially as 
> container, same as f´=, g=, and u=
>
> I do not see why it should be so tough to implement, as you are using 
> f=, g=, and u= the same way..

Actually the change only for some modules means you have to know which one should behave one way and which one behave the other way,
and have conditional codes, etc.
So doing it for all modules may be easier (well, less bad).

The main issue is that you have to deal with namespaces that are dynamically set, very different than working with specific element
of the core. On top of that a prefix can be mapped to several URIs, so you have to deal with things like hash maps of lists of
strings instead of just strings.
Remember that we want to core to work with the current modules/extensions and the future ones, without modifying the core.

Implementing the fragment identifier is one of the hardest part of implementing XLIFF2. This would make it even harder. I'm not sure
I can do it in a short time.
 
I really would like to see more than one implementation, especially with a language like XSLT. Any plan for that Bryan?

BTW: we still have to put some text (link) in the specification to point to the place where we'll define the registration of the
prefixes. Currently we say: "The prefix of a modules or an extension MUST be registered with the XLIFF TC (See [TBD: LINK TO
PROCESS])".

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