RE: [xliff] Issues

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, Bryan, all,

> Bryan, I think it fine to go with a list of allowed attributes,
> just make it short.

Well, it should be as long as it needs to be.
I hope the length of the specification is not a driving factor for what an XLIFF attribute can be or not be :)


> I wneted to look up how this is handled in meta,
> and figured that the meta attributes do not have conetnt 
> specified at all
> Would you mind specifying something?

The meta element is different: it’s an extension mechanism where you cannot define the kind of content it has (at least not in the XLIFF specification). Only tools that know the value of the type attribute can do something with the content.
It is truly like a custom namespace extension, but with more restrictions. There is a (very limited) interoperable aspect: the capability for any tool to display/edit the type and content (even if they don't know what it is).


> Ah, yes. The example is sent is flawed. The processing requirement 
> needs to say something like "The subFs MUST only be used to carry 
> attribute name/value comma-delimited pairs for attributes that 
> are valid for the HTML element identified by the accompanying fs."
> Example: fs:fs='img' fs:subFs='src,smileface.png' 
> "Commas in the value part of the pair must be escaped."

Don't forget to specify how to escape them.

If subFs holds a list of attribute and their values, why go to the trouble of having 2 attributes with specific syntax that tools have to parse then re-build into a tag? Why not fs="<img src='smileface.png'>" directly?
It would be as easy to break down for validation as it is to deal with fs/subFs.

For that matter maybe specifying what cannot be use may be easier (and shorter...)

cheers,
-ys