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] 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])".


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]