list4xt : Mailing list for the XT users community.
[list4xt] Re: HTML output handler proposed behavior
Subject: [list4xt] Re: HTML output handler proposed behavior
User: Website From: Mike Brown (mike@skew.org)
Date: 13/05/2000 - 20:28
> 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.
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.
> 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.
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! :)
> 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?
> 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 :)
> > 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 & 2
are < 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.
> 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.
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.
I see your point, and since you feel so strongly about it, I withdraw the
proposals.
- 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://floridamedicalmarijuanabusinessattorneys.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
|