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] RE: Re: subFs value and spaces (item 142) - not an official ballot, but please vote (straw poll?)

There's a rather inelegant but unambiguous solution to this. It would
require the fs module to define a long list of optional attributes and
corresponding constraints, so I'm not sure how feasible it would be in

For this example I'll use underscores rather than medial case, for clarity
of the concept.

We would still have the fs attribute, with the enumerated values
corresponding to supported HTML element names. To this we'd add the


...because these attributes are valid on virtually all HTML elements (and
possibly all of our supported elements; I haven't checked).

We could also allow the event attributes (onclick, onkeypress, etc.) which
are valid on most but not all HTML elements.

Following that, we'd have a list of fs attributes that represent specific
HTML element/attribute combinations:


...and so on. The list would be rather long, about 200 by my estimate. Note
that if fs="img" then fs_p_align would be meaningless and must be ignored;
only fs_img_* attributes would be acceptable.
The principle benefits of this approach would be that the HTML attribute
names would be incorporated in the XLIFF attribute names, rather than
embedded in the values; and the attribute values would be directly usable in
the generated HTML. We could even go a step further and constrain the
attribute types to correspond to the HTML spec, but ultimately it would
still be up to the processing agent to ensure the attributes correspond to
the HTML elements and that the values are appropriate in the HTML context.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On
Behalf Of Schnabel, Bryan S
Sent: Thursday, November 14, 2013 05:50 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Re: subFs value and spaces (item 142) - not an
official ballot, but please vote (straw poll?)

From XML's point of view (never mind XSLT for now), this is not an element:


This is a string of text that has an entity, followed by the letter p,
followed by greater than.
I can use Perl, for example, to convert it to <p>. Probably because Perl
does not care if the input or output are XML.

With XSLT 1.0 I could use d-o-e to do the same.

But there is no compliant XML parser that will treat that string as an

Further, this:

<someElement value="&lt;888>" /> 

is perfectly valid markup.
But if I used d-o-e in XSLT to serialize this, it would try to make an
element like this <888>.
And that is not a valid element name.

Whether we care about all of this or not is another matter. It sounds like
either solution will work. One advantage of (1) is that it lets us constrain
that only our prescribed set of HTML elements are used. And a second is that
it is XML-friendly (for what it's worth).

From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of
Yves Savourel [ysavourel@enlaso.com]
Sent: Thursday, November 14, 2013 1:31 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] RE: Re: subFs value and spaces (item 142) - not an official
ballot, but please vote (straw poll?)

> if we were to try to transform escaped XML into real XML in the output 
> stream

I'm afraid still don't understand the problem on the input side.
The input is not "escaped XML" it's normal HTML stored in an XML attribute.

> Since we cannot validate the escaped XML prior to processing it...

If the content of the fs attribute does not follow the XML syntax the XSLT
processor can't process that file. There is no need to "validate" it.

It sounds like you're saying XSLT processors don't parse/resolve character
entity references.

I think your issue seems to be with the output, where XSLT doesn't let you
mix plain text and HTML.
So your solution is to construct those HTML elements from structured
information you get from the FS attributes, instead of simply transferring
raw HTML. XSLT is probably the only programming language with that issue.

> Also, thanks for pointing out that by allowing escaped whole elements 
> in @fs we'd lose our constraint.
> I think that is huge. Without that constraint we would risk writers 
> introducing non-HTML elements via @fs. I see your point that they can 
> already introduce non-HTML attributes.
> However we do have processing requirements that prevent that.

I didn't see any PR that provides restriction on attributes.
How would you decide what is a risky element/attribute from a non-risky one?
One advantage of FS is to be able to provide more complex interactive
preview of the document, using for example scripts and onclick attributes.

It seems to me either the FS module will be very restrictive and not very
appealing (one could do almost the same with a XSLT stylesheet hosted
outside the XLIFF document), or it'll be powerful but need the user to
accept the risks.


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