Re: Re[2]: Thought on future of XMLC

On Thursday, Nov 21, 2002, at 05:13 Asia/Shanghai, Jacob Kjome wrote:

> Hello David,
>
> DL> This leads to another question. How many people are depending on 
> HTML
> DL> DOM (and for that matter, WML, cHTML or XHTML DOM) in their code?
> DL> Neither DOM4J or JDOM support these document specific DOM.
>
> DL> David
>
> I have to believe that most people using XMLC are depending, at least,
> upon the HTML DOM.  That shouldn't be a problem to continue to
> support, should it?  Otherwise, what is the alternative?

I probably asked the question in the wrong way. There is no immediate 
reason not to support HTML DOM. What I am doing now is refactoring the 
currently codebase to support some new feature. However, for the 
future, depending on how the community is using XMLC, this could impact 
on the way it evolved.

All of the specialize DOM (HTML, WML, cHTML and XHTML) are basically 
provide two things: an named interface and a set of convenient methods 
to access the underlying nodes and attributes. There are two types of 
programming style I have seen using these DOMs.

For example, in writing a simple setText(Element elm, String text) 
method for form element, there are two type of coding style:

1.
if (elm.getTagName().equals("INPUT")) {
        elm.setAttribute("value", text);
} else if (elm.getTagName().equals("TEXTAREA")) {
        // do the appending text child thing here...
}

2.
if (elm instanceof HTMLInputElement) {
        (HTMLInputElement )elm.setValue(text);
} else if (elm instanceof HTMLTextAreaElement) {
        // do the appending text child thing here...
}

The codes are equivalent but the first depending only on org.w3c.dom 
package while the second depending on org.w3c.dom.html package. The 
second one is supposedly "type safe," however, the org.w3c.dom.html 
package isn't well designed, resulted more tedious casting that 
necessary.

> We would
> have an XML document that would have to be transformed into XHTML via
> an XSLT stylesheet.  That could be made relatively fast if the
> stylesheet was pre-compiled, but the whole point about XMLC is that
> your mockups are your XMLC pages.  This makes development easy.  That
> said, using straight compiled XML and modifying that would make the
> document less presentation bound since multiple XSLT documents could
> define multiple different views of the same data.  In addition, it
> would still be easy to display the mockups since Both IE5+ and Mozilla
> contain XSL Transformers which can be run directly from the browser.

That probably won't give us the benefit. Even we don't have the markup 
specific DOM, we still deal with the semantic of ill defined HTML which 
mixes presentation and content.

XMLC's strength comes from being able to treat the whole mess of HTML 
in a more structured way. We would be dealing with a DOM tree instead 
of a very long text string representing the HTML document. No breaking 
up the presentations and mixing the work of web designers and 
programmers. The ID tagging gives programming the object favor in HTML 
programming, and leave web designers to their favor tools Dreamer Waver 
or FrontPage.

In XMLC, we work from real world by abstracting the order out of the 
chaos in the existing HTML. In XSLT, it works from assuming a clean 
content/presentation separation and try to create complex pages with 
it. They are very different approach to the same problem.

However, these XMLC approach and XSLT approaches are not mutually 
exclusive. They could actually be combined. For example, having XSLT 
rendering some part of the tree and attached to the XMLC render main 
page.

Well... I can't help ranting every time I see XMLC and XSLT in the same 
context. Better get back to coding. ;)

David