Re: Thought on future of XMLC

Hi Mark,

it mostly boils down to what do we do with invalid HTML (and how easy to use is XMLC). 
Since you joked about it: We did fire a html developer on the last project, we would send 
us some html and the developer who tried to check it into CVS found warnings from JTidy, 
then send it back to the html guy. That did cost us quite some time. His point is, it 
looks nice on all targeted browsers, if you mangle it and it doesn't look good any more 
it is your problem.

We are setting the bar a bit higher if we require html being corecct to the spec. Most 
html developers can live without the spec until they get to know XMLC and JTidy. On my 
other project, I am working with an external html design studio. Even though they are 
very capable, I again have to explain what correct HTML is and what not.

For me having html coded to the spec and using a presentation layer technology are really 
two things. Obviously other presentation layer technologies don't enforce correct html 
(JSP, struts, ASP,...).

Technically XMLC does not need to do that either, if it adopts the concept of not 
changing more of the original html as neccessary.

However, it insists on generating the HTML from nodes even if they were not changed 
(instead of taking the original HTML from the file), which makes it slower and IHMO more 
difficult to use.

One great thing about xmlc is, that it lets the html developer work the way they are used 
to (with static html). This being said, I don't think we should force them to validate 
their HTML, because that is not the way they work. I think the tools should work the way 
most people are used to work successfully on projects. (Not adapting the people to a way 
of working we think they should work.)

I am not talking about doing the right thing with invalid html. (which is also IMHO 
impossible) But why do i want to change portions of the original HTML if I don't have to? 
Changing them (that means generating them from the node tree, even though you could takes 
that part for the original html you have just parsed), is just slower, more error prone 
(we reported 2 bugs from JTidy in this project, don't even want to go into errors of the 
Swing parser) and forces us to code html to the spec, which difers from the reality in 
the browsers. (Even though it does not much difer, but anyway)

taking the design goal of xmlc serious, that it only supports valid documents, then why 
not breaking the build if xmlc encouters any warning? Why support the Swing parser? I 
think these two things are already kompromises.

I am not saying xmlc should support invalid html, but is not the job of xmlc to 
enforce it.

Arno



Mark Diekhans wrote:
> Hi Arno!!
>
> Arno Schatz <list@xxxxxxxxxxxxx> writes:
>
> > what you wrote is exactly what I did the last 3 years using XMLC. However,
> > on the various projects with XMLC i have seen
>
>
> >  - HTML developer mostly don't produce legal HTML (often I educate them
> > what legal HTML is and want not)
>
>
> Are these people actually producing HTML by hand or using an authoring tool?
>
>
> >  - HTML developer don't use HTML Tidy, even if I install it on their
> >   desktop.
>
>
> Umm, that is prety lame.  Maybe you need to fire them :-)
>
>
> >  - there are some cases where illegal HTML is wanted, like the
> >   'absmiddle'-attribute.  Netscape and IE support some proprietary HTML
> >   attributes, which will cause warnings in JTidy.
>
>
> XMLC has an option to tell jtidy about non-standard attribute (and
> even tags).  I think jtidy has built-in knowledge of what the netscape
> and IE attribute.  
>
>
> > HTML developers have a hard time already getting their code to run on all
> > desired Platforms (IE, Netscape 6, Netscape 4,...) which is a big pain. Now
> > we are asking them that their code should additionally be compatible with
> > the W3C HTML 4.0 spec.
>
>
> It would seem to me that a problem with portability is the fact that they are
> producting invalid HTML and using proprietary extensions.  Perhaps they need
> stick to what the tools are designed to do.
>
> IMHO, this is why so many web sites look nice, but are difficult to actually
> use.
>
>
> > The way HTML developers work is to view their HTML in all different browsers
> > and if it looks good then its ok.
>
>
> That's part of the problem; I bet they don't check in all of the different
> browsers, just IE and netscape.  Opera? Galeon?  etc...
>
>
> > And nobdy cares about the summary attribute in table-tags, which will cause
> > warnings in the compile process.
>
>
> Dave Raggett thinks it's important (author of tidy and the html spec).
>
>
> > Java developers also refuse to fix them, because there are so many of them
> > and they always are in a hurry. So the compile process is always full of
> > JTidy warnings, and it is just too easy to overlook the important ones.
>
>
> I really think that jtidy should be configured to treat things it wants
> to change as errors rather than warnings.  Things like summary would
> be warnings, but invalid document structure, etc would be errors.
> It's just guessing at what is expected, and this is not really a good
> idea. This was something I was intending to do but never got to.
>
>
> > That is why I like to see XMLC change the original HTML code as little as
> > possible.
>
>
> Since XMLC converts a document to an object hierarchy and then format's this,
> it's difficult to impossible to do `right thing' with invalid HTML.  Trying
> to support it will only compound the problem.
>
> If the goal is to use invalid html and just do string subtitution on it, XMLC
> is the wrong tool for the job.  It's a design goal of XMLC to only support
> valid documents.
>  
>
> > does that make sense to you?
>
>
> Your explanation makes sense, their attitude doesn't make sense. 
>
> Mark
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc