[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: HTML output handler proposed behavior

Subject: [list4xt] Re: HTML output handler proposed behavior
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 13/05/2000 - 22:47

Mike Brown wrote:
>
> > Your mail is interesting since it's showing a lack of a clear definition
> > of what the XHTML output handler is supposed to do !
> >
> > It has initially been developed to answer Simon's concern about XSLT ***
> > not allowing *** to generate XHTML conform documents.
>
> I'm sorry for the intrusion, then. My understanding was that the goal was
> to produce XHTML that is compatible with current-generation browsers that
> are not XHTML aware by design. The initial focus was on C.2 and C.3 from
> the XHTML 1.0 Recommendation, but you did ask if there were other points
> to implement.

Yes, the first goal was to allow to produce this XHTML, which is not the
case when you are using a XML method which does not meet C.2 and C.3.
My understanding is that a cautious developper can meet all the other
points of the C Annexe with the current release of the XHTML output
handler.
 
> I am not saying these *should* be implemented, only that if you are really
> wanting to go the distance, they will help further the goal of emitting
> XHTML that is in good form for compatibility.

I am not saying that it shouldn't be ;=)
 
> > In your answer, you are implicitly suggesting to go a step ahead, to
> > control the validity of the output and to modify the output tree in some
> > cases when necessary.
>
> Yes, and I was fully aware that emitting more or less than what can be
> found in the result tree plus xsl:output element is an unprecedented,
> possibly blasphemous and offensive act to some.

That's not what I have said nor meant either. Sorry if I haven't been
clear.
I meant that it was both more time consuming and more difficult.
A cautious developper which is sure of what he will generate may not
want to add a layer which will waste many cycles, especially if he is
generating XHTML on the fly.
 
> However, XSLT says the output, if any, can be any byte stream, and I have
> often pointed out when teaching people about the difference between the
> result tree and output, that the bytes you derive from the result tree
> don't have to constitute text, a markup language, or some other obvious
> representation of the tree. You could have an output method "monalisa"
> that outputs the bytes for a GIF that is a pretty picture of the Mona
> Lisa, with a multicolored mustache, with the colors of the mustache being
> determined by the contents of the result tree! :)

Absolutely.
That's what I find extremely powerful with specific output handlers :
you pipe the result tree into a SAX receiver which can do whatever he
wants.
 
> > I had envisioned this by proposing to use tidy as an output handler.
>
> Hmm, that would be cool. Is Tidy implementing the XHTML compatibility
> guidelines?

Yes. It would probably be time consuming as tidy needs to rebuild a DOM
with the result tree on which it does its checks and transformations.
The other option (to pipe it into a 2nd XSLT transformation) would be
also worth considering. It's probably much more flexible...

> > Isn't it the responsibility of web developer to make sure their document
> > has the right structure ?
>
> Of course. But I think you overestimate the capability of many web
> developers :)

Maybe...
 
> > > C.4 can probably be ignored, although you might kick out a warning if a
> > > <style> or <script> element has descendant comment or text nodes that
> > > contain < or & or ]]> or --.
> >
> > We are working with XSLT and it's quite hard to output these
> > sequences... And again, the developers can avoid doing it.
> >
> > > C.5 can probably be ignored, although again, a warning might be in order
> > > if an attribute value contains LF, CR, or a sequence of 2 or more LF, CR,
> > > tab or space characters.
> >
> > Same remark.
>
> I disagree that it is hard to output those sequences.
>
> XML over which the developer may have no control:
> <foo>1 &amp; 2
> are &lt; 3 </foo>
>
> XSLT:
> <xsl:attribute name="myAttr">
> <xsl:value-of select="foo"/>
> </xsl:attribute>
>
> Even worse, the source tree can be derived from a DOM tree, which means
> you can't assume much of anything. If I hadn't personally encountered this
> in my work I wouldn't think it to be that large of an issue.

I hadn't think of this. It's also a problem with the XML output method,
isn't it ?
I can add this one.
 
> > What do you think ?
>
> I have mixed feelings about my own proposals. I did not mean to raise your
> ire or insult the work you have done. You asked what else could/should be
> implemented and I suggested ways to do it.

You've not raised my ire. I appreciate challenging ideas...

> Whether it's right or wrong for an output handler to fix oversights in the
> result tree, as opposed to just making interpretations that produce output
> that is impossible to achieve with other methods or more careful
> construction of the result tree, is not an issue I was trying to address.

Again, piping into a second XSLT could do the trick. It could also have
many other applications.

> I see your point, and since you feel so strongly about it, I withdraw the
> proposals.

Please don't do it yet ;=) I'd like to get your thoughts about my answer
!

Thanks

Eric
 
> - Mike
> ___________________________________________________________
> Mike J. Brown, software engineer, Webb Interactive Services
> XML/XSL stuff: http://www.skew.org/ http://www.webb.net/
>
> --
> Mailing list for the XT users community. (http://heritagebank-stgeorge.com)
> (mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe) 

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://sponsordir.com
http://patriotbankcard.com -           http://cllshelton.org              http://upopassaic.org
------------------------------------------------------------------------

--
Mailing list for the XT users community.     (http://sponsordir.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)

Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET

webmaster@4xt.org
A site designed by Dyomedea