[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="<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]