Re: output html as lower case?

Another update.  I'm working with some of the Jaxen developers who have 
come up with a DocumentNavigator for the HTML DOM which allows for defining 
the case that you prefer the XPath to be evaluated.  It does this by 
forcing node names to the case you choose.  For instance, the following 
will work on the HTML DOM...

XPath query = new HTMLXPath("/html/head/title");

...where the following will not...

XPath query = new DOMXPath("/html/head/title");

The reason is that HTMLXPath, by default, forces element names to lower 
case even though they are stored in upper case in the HTML DOM.  One can 
also override the default by using another constructor...

XPath query = new HTMLXPath("/HTML/HEAD/TITLE", false);

...which is entirely equivalent to....

XPath query = new DOMXPath("/HTML/HEAD/TITLE");

The boolean constructor of HTMLXPath allows you specify "true" (the 
default) for lower case elements and "false" for upper case elements.  With 
HTMLXPath, you can now use the same XPath expression on both HTML and XHTML 
documents (or XML documents, for that matter).  XHTML and, hence, XML 
documents won't have the case conversion done to them to avoid breaking the 
XHTML spec where all elements are required to be lower case.

This should soon be in the Jaxen CVS.  I plan to use a build of Jaxen 
supporting HTMLXPath for the XPath demo in XMLC-2.2.

Jake

At 12:18 AM 6/25/2003 -0500, you wrote:

>Just a little update.  I asked on the Jaxen-interest list about treating 
>the HTML DOM in a case-insensitive manner.  The one response I got made it 
>sound like it isn't supported currently, but there is at least one (ugly) 
>workaround.
>
>Given the following XPath expression which would be valid for XHTML....
>
>"/html/head/title"
>
>would have to be modified to the following for HTML
>
>"/HTML/HEAD/TITLE"
>
>That is, unless one uses a nifty trick (some might call it a hack)
>
>"/*[name()='html' or name()='HTML']/*[name()='head' or 
>name()='HEAD']/*[name()='title' or name()='TITLE']"
>
>
>I actually tested that with Jaxen and it works.  However, JXPath returns 
>nothing.  Jaxen is much better about following the spec as far as I can 
>tell and if we are moving to DOM4J in XMLC-3.0, we will get Jaxen support 
>out-of-the-box, since that is what DOM4J's XPath implementation is based upon.
>
>Anyway, I'll keep on the Jaxen guys to support the HTML DOM in a 
>case-insensitive way.
>
>Jake
>
>At 11:24 AM 6/24/2003 -0500, you wrote:
>>At 08:33 AM 6/24/2003 -0700, you wrote:
>>>Richard Kunze <[email protected]> writes:
>>> > > 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.
>>>
>>>Guys, this will break tons of code and it will no longer be W3C HTML
>>>compatiable DOM.  This is a either a bug or missing feature in
>>>XPath, depending on your point of view...  Submit a patch to em, the logic
>>>for checking for an HTML doc is easy:
>>>
>>>     if (node.getDocument() instanceof org.w3c.dom.html.HTMLDocument) {
>>>         .....
>>>     }
>>
>>Agreed.  I'll ask the guys at Jaxen (used in DOM4j and elsewhere) and 
>>JXPath what their take on this issue is.  The XPath engine is probably 
>>where the case-sensitivity issues should be addressed rather than storing 
>>a non-standard DOM.
>>
>>Jake
>>
>>>_______________________________________________
>>>XMLC mailing list
>>>[email protected]
>>>http://www.enhydra.org/mailman/listinfo.cgi/xmlc