Re: output html as lower case?

At 04:55 PM 6/24/2003 +0200, you wrote:
> On Tuesday 24 June 2003 16:33,
> Jacob Kjome wrote:
> > Also, if we are to do this, would this solve the original problem
> > of the case-sensitivity of XPath?  That is, would the DOM
> actually be stored
> > in lower case so that XPath can search through the html dom in lower
> case or
> > would this only change the printing output of the html DOM? 
>
> Oops, yes - this would only change the printing. For solving the XPath
> issue, 
> we'd have to change the DOM implementation. 

That's what I figured :-(

> > If only the latter, then
> the  change is probably not worth the effort, 
>
> I agree.
>
> > but if the former, then this change would be very, very nice to
> have.
>
> Lets put it on the agenda for XMLC 3.0. A new DOM implementation is
> pretty 
> much a given for XMLC 3.0 anyway, so we can just as well include case
> insensitive XPath support for HTML.

Actually, if we could implement html dom level2 which just became a
recommendation, then we could do this and also get rid XMLC's
XHTML-specific stuff since with html dom level2...
http://www.w3.org/TR/DOM-Level-2-HTML/
http://www.w3.org/TR/DOM-Level-2-HTML/java-binding.html

Actually, now that I look at it, it may be that one would have to specify
the implementation as "XML" rather than "HTML" to get
this behavior.  See:
http://www.w3.org/TR/DOM-Level-2-HTML/changes.html
<quote>
The DOM Level 2 HTML module supports HTML 4 as well as XHTML 1.0
documents. Therefore, case sensitivity in methods depends on Document
support for the feature "XML" as well as "HTML".
<quote>

Anyway, I know that Xerces2 does not yet have an dom level2 html
implementation as of yet.  Maybe we can write it and contribute it
to the Xerces2 project?  Or just let them write it, if they already
have plans to do so.

In the mean time, I'll investigate Mark's comment where he mentioned that
maybe XPath should be case-insensitive in relation to the HTML DOM. 
That would solve the issue in a way that isn't dependent on us storing
the HTML DOM in a way that might break the specification.

Jake

> -- 
> Richard Kunze 
>
> [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
> http://www.tivano.de,
> kunze@xxxxxxxxx