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] Implementing extensions


Hi Bryan,

>>> I've seen files rejected for these reasons:
>>> - because the order of attributes in a custom element is
>>> different  than what the tool expected
>>
>> XML validation will not resolve this issue. If a given 
>> XLIFF tool cannot deal with the XML feature that attributes
>> order does not matter XLIFF should not take the blame for it.
>> The tool is to blame.
>> In other words: neither custom namespaces 
>> nor <metaHolder>/<meta> will solve this.
>
> [Bryan: how does <metaHolder> not help this? Rodolfo says 
> order of attributes causes the rejection. In this case 
> metadata would be not held in attributes, but rather in 
> elements. I think attributes go away - problem goes away.]

If the tool can't deal with re-ordered attributes in custom extensions, it's very likely that it can't deal with them in normal XLIFF elements either.

The problem here is not specifically related to custom extension.

In any case: we shouldn't try to design XLIFF based on the fact that some tool does not use an XML parser to read an XLIFF file. XML/XLIFF attributes can be in any order and the tools must support that.


>>> - because the program expected a custom element that is missing
>>
>> Validation against a schema certainly helps here.
>> But validating <meta> will not help because <metaHolder>/<meta> has 
>> no information about what data should be there. Only the schema of 
>> a custom namespace will solve this.
>
> [Bryan: My thickness causes me to not understand this statement. 
> <meta>/<metaHolder> will be parse-able according to the XLIFF extension
> schema. What information is needed about what data should be there?]

The schema for the XLIFF metadata can only state how <metaHolder>/<meta> are define. For example that the content of <meta> is a string.

For example <m:meta key="number-of-words">2</m:meta> will be valid.
But <m:meta key="number-of-words">schtroumpf</m:meta> will also be valid.

If we really want to *validate* the custom data you need a schema that says the data associated with number-of-words is of type number not string.

Validating against the schema a generic XLIFF metadata namespace is going to be too generic to be meaningful.
 
Worst: now because the users would have to use that XLIFF namespace, they would have no schema-based way to truly validate their custom data.

-ys




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