xsl:copy and xslt:copy-of change tags lowercase

RESOLVED INVALID

Status

()

Core
XSLT
RESOLVED INVALID
14 years ago
14 years ago

People

(Reporter: yu.mozilla, Assigned: peterv)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

2.84 KB, application/octet-stream
Details
(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.5) Gecko/20041108 Firefox/1.0

Mozilla XSLT seems to convert XML tags to lowercase whlie using "xsl:copy" or
"xsl:copy-of".  If there is an entry '<ID>1234</ID>' in a XML, it will converted
to '<id>1234</id>', which leads to result HTML page broken.


Reproducible: Always

Steps to Reproduce:
See attachment.
Note that contents of following XMLs are same, excluding XSL.
1. open data-all.xml, which displays ID and contents field (correctly)
2. open data-contents.xml, which displays contents field only (correctly)
3. open data.xml, which switches XSLs of step 1 and 2 , and press buttons. (BROKEN)

Actual Results:  
In step 3, pressing 'All' button results same result as 2.


Expected Results:  
In step 3, pressing 'All' button results same result as 1.


- My example uses "<xsl:copy>" in view.xsl. Using "xsl:copy-of" results same.
- IE treats this case well.
- Editing view-all.xsl to use lowercase like "<xsl:value-of select="id" />" 
  results step 1 to fail.
(Reporter)

Comment 1

14 years ago
Created attachment 175411 [details]
testcase XML/XSLs
This is a pretty complext testcase, so i can't say exactly what it is that
you're trying to do. But it seems like you're transforming part of an html
document using xslt?

XSLT doesn't work on HTML, it works on XML. HTML is case insensitive which is
what is giving you problems here. The reason this works in IE is that it has a
weird (though sometimes usefull) concept of xml-data-islands. It was decided not
to support this in mozilla, see bug 31331.

I propose that you instead create an xhtml document which will behave much more
like you want. I.e. make view.xsl start something like:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns="http://www.w3.org/1999/xhtml">
<xsl:output method="xml"/>
<xsl:template match="/">

I tried this and there are some other issues, but this should get you started.
One thing that you need to change is to make onLoad and onClick lowercase
(because xhtml is case sensitive).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

14 years ago
In my test case, XSLT is used two times:
  1. view.xml + view.xsl ----> html output #1
     (view.xml contents are embedded to html, using XML Data Island feature)
  2. html output #1 + view-all.xsl ----> html output #2
     (embedded XML is used to produce output)
The problem is, embedded XML data in html output #1 contains lowercased tags
(i.e., '<id>'), which are upppercase ('<ID>') in source XML.  As a result, 2nd
XSLT process produces illegal html output.

I guess this case convertion is not compatible with XSLT 1.0 specification in
http://www.w3.org/TR/xslt.html#section-HTML-Output-Method .

In the specs, they say "The html output method should not output an element
differently from the xml output method unless the expanded-name of the element
has a null namespace URI; an element whose expanded-name has a non-null
namespace URI should be output as XML. If the expanded-name of the element has a
null namespace URI, but the local part of the expanded-name is not recognized as
the name of an HTML element, **the element should output in the same way** as a
non-empty, inline element such as span."

The XML output method should preserve convert character cases (XML is
case-sensitive), and HTML output too.

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 4

14 years ago
Sorry typo...
> The XML output method should preserve convert character cases (XML is
> case-sensitive), and HTML output too.

The XML output method should preserve character cases (XML is case-sensitive),
and HTML output too.
(Assignee)

Comment 5

14 years ago
(In reply to comment #3)
> In my test case, XSLT is used two times:
>   1. view.xml + view.xsl ----> html output #1
>      (view.xml contents are embedded to html, using XML Data Island feature)

XML Data Islands are not supported in Mozilla, whether directly or as a result
of an XSLT transform.

> I guess this case convertion is not compatible with XSLT 1.0 specification in
> http://www.w3.org/TR/xslt.html#section-HTML-Output-Method .

BTW, that part of the spec is optional, and we're free to ignore it (we don't
serialize).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → INVALID
(Assignee)

Comment 6

14 years ago
BTW, you really need to simplify your testcases if you want to convice us. One
xml file, one xslt file. And you talk about view.xml, which is not in the zip.
Even if we preserve the case in both xml and html while outputting the result,
that result is then fed into an html parser to generate the page you see [*].
The html parser is, and has to be, case insensitive. That goes for the entire
document as mozilla don't implement data islands. So once you have an html
document there is no such thing as upper or lower case tags.

What you then do is to feed part of this html page into an xslt processor. Right
there you enter into unsupported terratory as xslt works on xml, not html. It
just so happens that it semi works, but you get weird artifacts such as the case
problem you are seing. That is not a bug but an unsupported behaviour.

What could be argued is a bug is the fact that we try to perform the
transformation. We should maybe throw an error saying that you can't perform
xslt on html. You could also argue that we should support xml data islands, but
that is a different bug then this one.

As I said before, if you want to put xml data inside your document use xhtml.

[*] This is not actually how it's implemented in mozilla, but that's an
implementation detail and doesn't have a practical effect in this case.
You need to log in before you can comment on or make changes to this bug.