- From: <bugzilla@jessica.w3.org>
- Date: Fri, 02 Mar 2012 14:20:45 +0000
- To: public-i18n-core@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16166 --- Comment #5 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-03-02 14:20:41 UTC --- (In reply to comment #4) > I'm aware that you can use lang in all the formats served to the browser as > html, 1) While you know, most authors do not know xml:lang can be skipped 2) Your terminology differ from HTML5. Hence, I'm unsure what you mean: Files: It sounds like you describe 'application/xhtml+xml' as HTML. Whereas HTML5 describes 'application/xhtml+xml' as 'XML' http://dev.w3.org/html5/spec/history.html#read-xml Elements: The @lang issue is element - not format - level: "'HTML elements' when used in this specification, refers to any element in that namespace, and thus refers to both HTML and XHTML elements" http://www.w3.org/TR/html5/infrastructure.html#html-elements Please say 'generic XML' if you want to exclude "application/xhtml+xml". > and if that would solve the problem I wouldn't raise this issue. But > polyglot is not just about serving to browsers. > > The issue is that you need xml:lang if your document is to be treated as *XML* I read that as 'treated as *generic* XML'. > - which is the point of using Polyglot documents. The point with polyglot html is *postprocessing* with XSLT??? > For example, XSLT picks up on > xml:lang for its lang() function, but not on the lang attribute, which has no > more meaning to an XML processor than a 'language' attribute, or a 'foobar' > attribute. In my reading, you are mistaken about XSLT: There is no purpose for xml:lang, from XSLT's point of view, except when the XHTML document is supposed to be post-processed with XSLT. How often is that? Here is my detailed justification for this conclusion: 1) For XSLT 1.0 elements, there is only a 'lang' attribute, which takes the values that xml:lang takes. XSLT 1.0 for that reason gives an explanation of how to "circumvent" this "problem": ]] The following example shows how xml:lang attributes can be easily copied through from source to result. If a stylesheet defines the following named template: < skipping the code example > [[ http://www.w3.org/TR/xslt#element-copy XSLT 1.0 also says it more directly: ]] NOTE:The xml:lang and xml:space attributes are not treated specially by XSLT. In particular, it is the responsibility of the stylesheet author explicitly to generate any xml:lang or xml:space attributes that are needed in the result; specifying an xml:lang or xml:space attribute on an element in the XSLT namespace will not cause any xml:lang or xml:space attributes to appear in the result. [[ http://www.w3.org/TR/xslt#section-Creating-Text 2) XSLT 2.0 fails to provide any examples that involve lang. But it does say that xml:lang is treated like a "standard XSLT attribute" (below this paragraph: http://www.w3.org/TR/xslt20/#err-XTRE0795). And that is treated as a standard attribute (http://www.w3.org/TR/xslt20/#standard-attributes) has to mean that one uses xml:lang directly (inside XSLT elements) rather than lang. However, that xml:lang is treated like a native attribute, leads to a conceptual and practical "problem": XSLT2 users must take an extra step in order to get the processor to *output* xml:lang. Namely, they must use namespace-aliasing in order to insert any xml-prefixed attribute into the - in our case - XHTML output. http://www.w3.org/TR/xslt20/#namespace-aliasing XSLT2 gives an example of how to do this with xml:space, explaining that is is also relevant for xml:lang: ]] This allows an xml:space attribute to be generated in the output without affecting the way the stylesheet is parsed. The same technique can be used for other attributes such as xml:lang, xml:base, and xml:id. [[ http://www.w3.org/TR/xslt20/#d5e15762 Thus, it does not sound - to me - as if XSLT 2 has given the output of xml-prefixed attributes a very high priority. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug.
Received on Friday, 2 March 2012 14:20:55 UTC