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


And now that I think about it, since the fs module is offered on many XLIFF elements, rather than showing all fs optional attributes on each element in the spec, it seem friendlier to add a link to the table of optional elements for each element that allows them.
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Schnabel, Bryan S [bryan.s.schnabel@tektronix.com]
Sent: Thursday, November 14, 2013 3:53 PM
To: Tom Comerford; '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?)

I like this. I like this a lot.

A long list of attribute, in my opinion, can be justified if it eliminates ambiguity, guess work, and interpretation.

This would be quite easy for XML and non-XML programming languages to parse.
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Tom Comerford [tom@supratext.com]
Sent: Thursday, November 14, 2013 3:40 PM
To: Schnabel, Bryan S; '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?)

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

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
following:

        fs_class
        fs_dir
        fs_id
        fs_lang
        fs_style
        fs_title

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

        fs_p_align
        fs_img_src
        fs_img_alt
        fs_img_align

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

<p>

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

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.

Cheers,
-yves



---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





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