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] possible issue with URN prefixes used to define acceptable namespaces in XLIFF 2.1

>> We would simply define a rules file with all the rules 
>> mapping the XLIFF ITS module to ITS.
>> A pure ITS processor would just use that file.
> Wouldn't it be possible to use the rules element at the file level? 
> to avoid referencing an external rules file? 

One could do this, but I'm not sure it's very practical:

a) Any processor that can process global rules must be able to process external files. The rules file will always be the same so there is no point duplicating all over the place. In addition I would expect very few ITS-only processor to process XLIFF files (compared to XLIFF processors)

b) Having a rules element at the top would somehow implies that the XLIFF processor should be able to process it too. And we said that was not going to be the case. (All ITS markup in local).

>> Fredrik suggestion has several advantages:
>> - It decouple ITS and XLIFF namespaces
> Not sure if this is an advantage.. 

>> - We would need only a single namespace for the module 
>> (doing the job for both the ITS one and the supplemental one)
> I think it could be useful to keep them apart to be clear on what a exists 
> locally in generic ITS and what had to be "made up" for XLIFF puposes. 
> I guess could be useful for extractor/merger implementers. 

Actually, let me correct my statement: None of the markup in the module namespace would be ITS anyway (It's really all like a supplemental one) so there is no need for two namespaces.

>> - It would allow both namespaces to evolve (be updated) separately if needed
> I think that this is the only disadvantage of this solution: supporting 
> the namespaces in two separate locations, under separate authorities, 
> is error prone and an opportunity for divergence.

Not if they are versioned.

Now, the sooner someone start the mapping, the better to catch potential issues with this.


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