Le grande pinguin said at 17:46 8-4-2002: > > 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.
It's the same goal: providing content, which doesn't conflict with browsers, and is parseable by XML parsers, so that transforming content completely to XML is made possible. It's really to accomodate humans that 'know tags' and CMS apps, that need complete reworking, if the web is to become all XML. > > So - all these 'non-standard' issues "Le grande pinguin" talks about, are > ^^^^^^^^^^^^^^^^^ > sorrry for that, that's a practical joke of my sysadmin :-/ Ralff it is, missed that on the first mail :-) I always quote nicknames, please don't be offended, I will promise to take my pills which should cure this compulsive behavior :-) > > 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. And since you're providing XHTML, including DOCTYPE, your output is valid :-). It allows one to create 1 output-stream, for all browsers (that is, if design permits it of course) and provide x-tra functionality for browsers that do understand namespaces and custom tags. One could think of extra helpers, or links to encyclopedia's created on <ENC> tags, on the fly. The ENC tag will be ignored by lynx, NS4 etc, but will trigger a dom-function onload. Something I use quite often. In a stage of redesign, when the backend has finally merged to complete XML, one can extract those custom tags and re-format them, so you keep archives, and give them the meaning they should have. > 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. But - for XHTML they are limited and it's XHTML you're providing. In the scenario above, this would be considered XML INPUT and so it's parseable by the processor, even if it's <a />. >The xhtml specs only talk in Appendix C (HTML Compatibility Guidelines) >about this >issue. Yes, they tend to put the important stuff somewhere you don't look :-) >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. Isn't that just name-calling? As far as I can tell, an XSL application without an output serializer, isn't an XSL application, cause it won't correctly conform to the xsl:output specification. > 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). Exactly - that's why the XSLT 2.0 draft, now provides the new output method. Unfortunately - it's still a draft and it's version 2, so for Chris, I doubt, that support for this output method will come any time soon. If you want it, you should patch LibXSLT - the C version, not the Perl version, or make a an OutputTransformer in AxKit, which fixes up the XML output-method. It should be farely easy, since you would simply put a space into <[\w+:\-]/> and replace <[[:block-elements:]]/>, so to speak. I think it would work fine as a temporary work-around. 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]
