OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-omos] Handling unsupported modules and extensions


> For all modules, even unsupported ones, the schema is known, and that means we have the 
> typing information available to convert it from one format to another correctly.

The reason I see an unsupported module as the same as an unknown extension is because both have data without correspondence in the tool's object model.
I'm not sure we can assume a tool not supporting a given module will do anything with the schema of that module.

I guess there are several use cases of conversions:

1) JLIFF to OM to JLIFF
2) JLIFF to OM to XLIFF
3) XLIFF to OM to JLIFF

1) JLIFF to OM to JLIFF

I have not tried, but I assume there is likely a generic way to store such data in the object model, for example using whatever JSON object the tool implementation uses. There is no need to do conversion to classes of the OM and the tool can still read and write back the data without losing information.
The only thing the object model would need to implement is a way to store and retrieve generic JSON objects in its structure.

2) JLIFF to OM to XLIFF

Here the main problem seems to be that, in some cases, there will be no way to decide if a set of fields should be output as attributes or elements.
Except if that information would be coded as some kind of annotation in the schema, I'm not sure even that even knowing the schema would help for this.
Another option would be to have some kind of naming convention that distinguish attributes from elements. But that is probably too much to ask for.

3) XLIFF to OM to JLIFF

Here the main issue comes from the lack of type information in the XLIFF side.
One could probably infer some (like 123, true, "text") but it won't be complete. So, one would have to rely on the XSD schema for the information.

It seems to me that to be able to truly do conversions back and fore in any direction, the OM itself needs to know the type of the field and whether when it's in XML it's an element or an attribute (at least for the ambiguous cases).

Just thinking aloud...
-ys


From: Chase Tingley [mailto:chase@spartansoftwareinc.com] 
Sent: Friday, November 3, 2017 11:14 AM
To: Yves Savourel <ysavourel@enlaso.com>
Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: Re: [xliff-omos] Handling unsupported modules and extensions

No, I was just saying that there are cases where we can't guarantee that the data types are preserved, and this is bad, but it's also within the language of the spec.

I think there's a difference between custom extensions and unsupported modules, however.  For all modules, even unsupported ones, the schema is known, and that means we have the typing information available to convert it from one format to another correctly.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]