RE: [xliff] Implementing extensions

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Yves,

Please see my comments below, in the text.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: Wednesday, March 21, 2012 8:52 AM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Implementing extensions
> 
> Hi all,
> 
> The item "Preserve metadata without using extensibility" is a misnomer since
> the proposal is actually about how to store the data of extensions.
> 
> I think it was meant to say "Preserve metadata without using namespaces"

Wrong assumption. The proposal is to create an optional module, that would use namespaces.

As the data we are talking about is not absolutely required for creating a translatable XLIFF document, it is not a core feature and should live in a module as we agreed beforehand.

 
> The proposal defines a set of elements <metaHolder>/<meta> to hold any
> data tools cannot put in other attributes/elements. Basically it describes one
> way of representing extensions.
> 
> As we started to discuss during last call, I think we need to compare that
> proposal with another way: which is to use namespaces like in v1.2.

The proposal uses namespaces. Please check the examples I sent to the mailing list.

 
> Here is a list of some pros and cons for both methods:
> 
> 
> === XML natural
> 
> -- ns.pro) Namespaces is a standard XML mechanism to mix different
> vocabularies. All the XML technology stack understand namespaces and can
> work with them. It's a built-in mechanism, why invent something different?

We are using namespaces for this.

 
 
 
> === Acceptance of namespaces
> 
> -- ns.con) Some tools are not implementing namespaces properly in v1.2 and
> find it complicated and cumbersome.
> 
> That may be true. But it's a tool problem. Namespaces are part of XLIFF
> especially now that we use them for modules. Using them for extensions
> does not add any specific burden. I would also add that quite a few tools
> have welcomed the use of namespaces in v1.2.

Namespaces are accepted, not a problem.

> === Validation
> 
> -- ns.pro) The extensions can be well documented and validated using
> schemas.

That's not what happens in real life. Custom schemas has been kept secret for a long while. They are not secret today but they are not documented at all.

The problem is not related to XML namespaces, the problem is the abuse on the namespace mechanism that we have today. 

 
> -- ns.con) A drawback I've heard at the meeting was that with namespaces
> the document cannot be validated if the corresponding schema is not
> available.


All we can validate today is well formedness. We cannot validate if the required elements and attributes are present in the right place.

 
> I don't think that's correct: we already have unknown namespaces allowed in
> <skeleton> for example. That doesn't seem to be an issue. So why having
> <xs:any> used in other places with processContents="skip" or
> processContents="lax" would be a problem?

There is an actual problem today. Tools that use custom extensions reject files that are valid from XML point of view and XLIFF point of view.

I don't like what have in <skeleton> in current draft. Allowing XML from any namespace in the skeleton is as bad as allowing it elsewhere. I added that to the draft specification and schema because there was a formal request.


> Could we clarify the validation issue that was raised and see if there are
> solutions?
 

Custom XML schemas should be known and available for validating XLIFF files that use custom extensions. Without them, it is not possible to check if all required elements and attributes are present.
 
One possible solution is to mandate that custom schemas be embedded in the XLIFF file, as Microsoft does with ResX files. 


> === XLIFF evolution
> 
> -- ns.pro) We are already using namespaces for modules, so using
> namespaces for extensions is a natural way to build up and test a tool-
> specific feature that may become an official module later. In other words it
> allows for a straightforward way to evolve XLIFF.


That's right. 

 
> -- bag.con) With the <meta> method when we want to make a custom
> extension an official module we would have to re-define it in its namespace,
> and possibly change how it is coded (since <meta> has restrictions the
> namespace does not have). Tools would have to be adapted instead of just
> switching namespace.

Remember that <meta> would live in its own namespace.

 
> === Keep simple extensions simple
> 
> -- ns.pro) Using namespaces allows simple metadata to be represented very
> simply: just with an attribute for example.

Once again, <meta> would live in its own namespace.

 
> -- bag.con) Using <meta> makes even simple extensions more complicated
> to define. For example if I need to set a single metadata value on a <ph>
> element I'll have to stuck it somewhere as a separate element with some
> idref. It's more verbose and more complicated to associate the data with the
> element to which it pertains. For example:
> 
> <segment>
>  <source>The price is <ph id='1'></source>  <metaHolder>
>   <meta key='myData' idref='1'>value</meta>  </metaHolder> </segment>


There is no need to use id/idref. In fact, the examples I sent to the list don't use  that mechanism.

 
> With a namespace it's simple:
> 
> <segment>
>  <source>The price is <ph id='1' xyz:myData='value'></source> </segment>


Yes, it is simpler and nicer.


> === Allow complex extensions to be simpler
> 
> -- ns.pro) Using namespaces allows complex extensions: you are not limited
> in a set of key/value pairs.

Right. 
 
> -- bag.con) It makes the more complex extensions very verbose and
> potentially a lot more complicated to define. Anything that goes beyond a
> flat set of key/value pairs will be difficult to define and use.



Not really. Custom extensions can be more complicated than the proposed module.
 
 
> === Re-usability
> 
> -- ns.pro) Using namespaces would allow to re-use existing vocabularies for
> things not defined in XLIFF itself.
 
The key is in "things not defined in XLIFF itself". We see extensions used for things that XLIFF already contemplate.
 
 
> === Control of processing expectations
> 
> -- bag.pro) With <metaHolder>/<meta> the specification can set processing
> expectations that, for example, force or forbid different things.
> 
> True. But the same processing expectations can be set for non-XLIFF
> namespaces used in XLIFF.
 
We don't have any real proposition for setting processing expectations on custom name-space based extensions. 
 
> === Miscellaneous
> 
> -- ns.pro) With namespaces, dealing with optional modules and custom
> extensions is basically the same thing for the tools that choose to support
> just the core.
> 
> -- ns.pro) With namespaces there is no risk of clash between different
> metadata. I suppose we could have tool-specific prefixes for the key names
> for the <meta> element, but this is less verifiable than the namespace
> mechanism.
> 
> 
> Any additional pros/cons?

Just to clarify: custom extensions based on namespaces could be good if their implementation is well regulated. Unfortunately we cannot control what tool vendors do.