RE: [xliff] possible issue with URN prefixes used to define acceptable namespaces in XLIFF 2.1

Hi David, Yves,

I assume that the intention is to map as many of the ITS data categories onto existing XLIFF Core and Module features as possible and use new constructs in the ITS mapping Module only where there is no existing feature to map it onto or where the semantics are different enough to warrant it. For example for the ITS size restriction to SLR mapping I hope that we can end up with a mapping where only the cases where the existing profiles are unsuitable would use an explicit ITS SLR profile. I think we might be able to use existing only features for the common case where ITS uses UTF-8/16/32. For other encodings an ITS specific profile would be necessary.

An advantage of the above is that existing XLIFF processors would be able to support many of the data categories mapped from ITS data both for consumption, modification and enrichment. I think the latter two need extra care in the mapping specification. It would be highly desirable if a merge agent could update and add ITS information to the resulting file also in the case where the information was provided by an XLIFF agent not directly supporting the ITS module.

> >> 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:
> 
I really like the idea of an external ITS global rule file that is static for all XLIFF files, that would be the absolute best way to allow ITS only processors to extract information from XLIFF files or apply validation. Since the rules would be static and common to all XLIFF files it would not make sense in the general case to place them directly in the XLIFF file. An agent wishing to do that should be able to do so using our existing extension point though.

> 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..
I strongly believe this is an advantage. As I argued earlier only a subset of the ITS data categories would be represented in XLIFF using elements and or attributes in an ITS mapping Module. The other subset would be represented by other XLIFF Core or Module constructs. That means that an ITS only processor would at best only be able to process a subset of the data categories even if the ITS mapping Module directly used the ITS namespace. Using an XLIFF specific namespace would make it clear that a processor would need to support the XLIFF specifics, or if implemented make use of the external global rule file.

> >> - 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.
> 

Regards,
Fredrik Estreen

Received on Wednesday, 8 October 2014 12:38:14 UTC