On Mon, Apr 08, 2002 at 05:18:47PM +0200, Melvyn Sopacua wrote:
> At 17:05 8-4-2002, Christopher H. Laco shared with all of us:
>
> >Well, let me play devil's advocate then....
> >
> >If XHTML is valid XML via method="xml". why on earth is method="xhtml" added
> >to the 2.0 working draft?
> >
> >Two reasons I can think of..
> >#1. text/xml vs. text/html content-type.
> > Can be fixed vy using media-type="text/html", assuming the
> > processor uses
> >it
> >
> >#2. In XHTML <p></p> != <p />, while in XML it does, if for no other reason
> >than from a rendering standpoint.
> > Which is my point, When I put in <p></p>, I want exactly that
> > returned to
> >me.
>
> Yes, and because it's the core reason for creating the XHTML-spec:
> To create Well-formed XML, that is backwards compatible, with existing
> user-agents.
Interessting view, but as i read the documentation the main rationale behind
the xhtml draft is to creacte an XML syntax that duplicates and extends the
HTML-4.x SGML syntax.
> So - all these 'non-standard' issues "Le grande pinguin" talks about, are
^^^^^^^^^^^^^^^^^
sorrry for that, that's a practical joke of my sysadmin :-/
> in fact,
> specified as a standard - and - even more, they do not CONFLICT with XML and is
> therefore standard conforming output.
Sorry, but i only commented on '<br />' _not_ being HTML-4.x being not standard
conformant. Yes, '<a/>' and '<a />' are both valid XML, but again, according to
the specs. the are (and need to be) interchangable. The whole idea of XML is that
this kind of external representation should be absolutely transparent to the
application.
The xhtml specs only talk in Appendix C (HTML Compatibility Guidelines) about this
issue.
As i said before, i see the problem, but it is one that needs to be solved by
the output serializer and _not_ the transformer. And, (un)fortunately, since
the output serializer has no way to 'see' the input document (if there ever was
something like that) the encoder would have to 'know' about the special recomendations
of the xhtml specs (and AFAIK libXML does exactly this). The only way to save input
encoding information would be to annotate the nodes of the in-memory tree and that
seems like putting a highly application specific task into a generic code library.
Ralf Mattes
>
> > > It doesn't fit 'html', but why not 'xml' methods. AFAIK xhtml
> > > is perfectly
> > > valid xml. I get the impression that you want/need to feed
> > > xhtml to non-
> > > xml aware browsers by faking something digestable to those
> > > broken implementions
> > > (the 'ol <br /> hack :-) Curse on the browser industry, not
> > > the XSLT implementors.
> > > You ask them to do the same mistake again (producing
> > > non-standard conforming output).
>
>
>
> Best regards,
>
> Melvyn Sopacua
> WebMaster IDG.nl
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> If it applies, where it applies - this email is a personal
> contribution and does not reflect the views of my employer
> IDG.nl.
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
