Re: [xslt] xhtml output

[Daniel Veillard <veillard redhat com>]

On Fri, Nov 29, 2002 at 12:05:11AM +0100, Daniel Stodden wrote:
> >   You're the first one to ever request it. If you want to remove
> > indentation walk the tree and remove the blank nodes using the API.
> > XML is very clear about it, any cdata, even blanks are significant.
> > If I am requested to add some for indenting, I do, but removing
> > I won't, far far too dangerous !
> 
> ok. yes, i'm aware of the issues.
> but i'm also aware that it does not hurt as long as it's performed only
> on explicit demand, in the same manner whitespace is currently added.
> what i thought of was roughly equivalent to whitespace stripping in
> xslt, and that is perfectly fine if happening on demand.

  That's perfectly fine to be left outside the API since so far I didn't
see anybody giving a realistic use case of why this is needed at an 
infrastructure level. Indenting is part of the infrastructure because 
it's an operation mentionned in existing standards and needed for implementing
those. I see no such requirement for stripping and it can be done on top
of the API, so I don't see why it needs to be integrated to an already too
complex API !

> > > regarding xslt: so support for method=xhtml in xslt is in the works?
> > 
> >   No. Checking an XHTML1 doctype is more reliable. This might be needed
> > for XHTML2 if it ever get supported but not urgent ATM. I may export the
> > currently private funtion to specifically save XHTML nodes in that case.
> 
> my problem is: i don't see where the appendix C stuff is called
> normative within the xhtml 1.0 specification. from my understanding it
> is not.

  Appendix C is not. Section 3.1 defining how conformant documents can be 
detected is normative. And heck even XSLT serialization is NOT required
normatively, should I just say you're arguing about non-normative stuff ?
In that case the current behaviour is REQUIRED to have PRACTICAL working
implementations of XSLT transformations output and XHTML1 serailization,
it does NOT break any spec, it actually FOLLOWS their advices, and you're
complaining. I want to know WHY before spending further time on this !

> basically, there are currently two totally different ways to serve
> xhtml: text/html or xml. right? the current behavior of xmllint is to
> enforce text/html-capable output. that does not hurt. however, it may
> actually be unnecessary and _not_ desired. nor i see where it is
> required.

  It does not hurt. Please don't hurt me, then, give me a break, come
with a counter example where the change are giving a problem, and I will
advise. So far you're only complaining about "could", "may", "not required"
but not giving up serious argumentation about effective failures. I have
only so much time for coding and maintainance, I don't want to get into
a rathole of maybe's, if you have a bug submit it, if you want to extend
the API justify it. If you want to bypass the XHTML1 serialization 2mn of
examination of that code base will give you a way to turn around it :
write the XML decl, and the doctype yourself, unlink the doctype, call the
API, relink the doctype, done ... no need to argue for hours around this.
Same think, if you want to strip indenting, nothing prevent from doing it
at the API level, so what ? Changing the API is driven by the 80/20% rule.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/