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

list4xt : Mailing list for the XT users community.

[list4xt] Re: XHTML output handler proposed behavior (was Re: ...nits)

Subject: [list4xt] Re: XHTML output handler proposed behavior (was Re: ...nits)
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 13/05/2000 - 09:03

Hi Mike,

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.

The XSLT users have very limited control over the actions taken by
either the XML or the HTML output handlers and none of them, if they are
conform to the XSLT specifications can output a XHTML document (the HTML
output handler doesn't output well formed XML and the XML output handler
doesn't comply with empty element minimization).

The only solution would have been nasty tricks such as using a text
output and generating your tags by hand, but I don't even want to
consider this ;=) ...

I think that the XHTML output handler in its current state is solving
this first goal and allows (but not forces you) to generate conform
XHTML documents.

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.

I had envisioned this by proposing to use tidy as an output handler.

Another solution would be to use a second XSLT transformation as output
handler which would do the checks and adjustments.

I just wonder if it's the right way to go.

Isn't it the responsibility of web developer to make sure their document
has the right structure ?

You could as well check the whole XHTML DTD and verify that the root
element is html, that you've got a unique body element and so on...

Is this reasonable and even useful ?

It would be very time consuming since you've got to rebuild the whole
tree of the output document to do this (like tidy is doing).

An advantage could be to generate documents depending on the user agent
(you could generate IE HTML for IE <= 4, Netscape HTML for Netscape <=4,
XHTML for more recent browsers, ...).

All the logic of the stylesheet would remain the same and the output
handler would do the adjustment.

This said, let's see each of the bullets :

Mike Brown wrote:
>
> Eric van der Vlist wrote:
> > Is there anything else than the C.2 and C.3 appendixes to implement ?
>
> Surely!
>
> C.1 can be acknowledged by allowing processing instructions to be
> optionally omitted from the output, either as an automatic process based
> on the target browser (if the "adaptable" handler is implemented), or via
> an attribute on xsl:output that acts like a switch.

I'll check this point.

> 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.

> For C.6 through C.9, I propose that the output method add or remove
> elements and attributes:
>
> For C.6: Only output the first <isindex> element encountered in the
> result tree.

This is typically something which would need to work on the output tree
and on which the developper already has control.
 
> For C.7: If there is a 'lang' attribute but no 'xml:lang' attribute,
> output an 'xml:lang' attribute with the same value as the lang attribute.
> If there is an 'xml:lang' attribute but no 'lang' attribute, output a
> lang attribute with the same value as the 'xml:lang' attribute. If both
> are present, output both as-is.

id.

> For C.8: Add an 'id' attribute to elements that have a 'name' attribute.
> Do not add a 'name' attribute to elements that have only an 'id'. A
> warning should be issued if the 'name' and/or 'id' attribute values do
> not match the Name production. I would not worry about checking fragment
> identifiers in URIs that may be in the document.

id.
 
> For C.9: If there is a <head> element, add a
> <meta http-equiv="Content-Type" content='text/html; charset="foo"'>
> element as its first child. "foo" must be the same encoding identifier as
> was used in the prolog.

id.
 
> C.10, C.11 and C.13 can be ignored.
>
> C.12 can be easily enforced: on output, convert any "&" that is not
> followed by "amp;" in an attribute value to "&amp;".

This is already the case.
 
> Thoughts?
>
> - Mike
> ___________________________________________________________
> Mike J. Brown, software engineer, Webb Interactive Services
> XML/XSL stuff: http://www.skew.org/ http://www.webb.net/

What do you think ?

Thanks

Eric 

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://inkwellbookstore.com
http://merchantaccounts.co -           http://strasburgsavingsbank.com              http://merchantfundingnetwork.com
------------------------------------------------------------------------

--
Mailing list for the XT users community.     (http://texascountrybank.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