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] Issues

I think I have (nearly) all the information I need to make the updates. I like the idea of removing the need for subFs by overloading the fs.

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

I'll take it even further, what value does the "<" and the ">" add? It is clear in the spec that we're talking about HTML elements.

Why not fs="img src='smileface.png'" ?
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Dr. David Filip [David.Filip@ul.ie]
Sent: Friday, April 12, 2013 5:26 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Issues

Thanks Yves, inline

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie<mailto:david.filip@ul.ie>

On Fri, Apr 12, 2013 at 1:06 PM, Yves Savourel <ysavourel@enlaso.com<mailto:ysavourel@enlaso.com>> wrote:
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).

I understand that, but in the interest of interoperability, a pattern should be specified, proponents of the module keep talking about key value pairs but there is nothing like this written in the spec. How are the consumers supposed to know that this is how they use them? Is this a secret tribal understanding?
Mayb n-tuples could be specified, just not nothing, IMHO

> 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="&lt;img src='smileface.png'>" directly?
It would be as easy to break down for validation as it is to deal with fs/subFs.
+1, I always get slightly uncomfortable, when I hear of lists of comma delimited values, what Yves, suggests makes much more sense than having processors reconstruct the HTML syntax
@Bryan? Is this doable by today?

For that matter maybe specifying what cannot be use may be easier (and shorter...)
@Bryan, it's up to you..


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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