why distinctions within XHTML?

[Mark Birbeck]

David Hunter wrote:
> ... And I love the idea of being able to embed 
> XHTML fragments into other XML vocabularies, such as
> 
> <order>
>   <customer>Fred Jones</customer>
>   <comments xmlns="xhtml-namespace">
>     <p>Bought <em>500</em> units!</p>
>   </comments>
> </order>

[snip]

> What I don't see is why any of this means that we need to 
> distinguish the three flavours of XHTML with separate
> namespaces.

[snip]

> I'm worried that if the three current flavours are
> distinguished by namespaces, it makes it much harder to 
> bring them all back to one eventually, but that instead
> there will always be a strict, and a loose, and a frameset.

[snip]

> In other words, any application which is working with XML can 
> just look for that namespace and say "oh, this element is using
> XHTML.  I'll hand it off to the XHTML application to process".

David,

My argument is that in the future, version >1 of XHTML will be
modularised and so you will actually do this:

<order xmlns="myorderstuff" xmlns:bl="xhtml.block.text.module">
  <customer>Fred Jones</customer>
  <comments>
    <bl:p>Bought <bl:em>500</bl:em> units!</bl:p>
  </comments>
</order>

Note that I've moved the namespace definition down a level from
'comments' because you wouldn't put it there. All you would need to do
would be to define in your schema that 'comments' can have children from
the 'XHTML block text module'. (Quite why David M thinks each new
namespace should be at the 'comments' level is baffling me. A million
namespaces!?!) In other words, you won't be using 'strict',
'transitional', or anything. In terms of post-parsing processing, in
this scenario a 'p' is a 'p' is a 'p' (as everyone wants, albeit a bl:p
now, instead of a generic html:p). However, at the moment none of this
exists, although it is a stated goal of XHTML. (If you haven't already,
have a look at the modularization document - it's very impressive.)

So, even if you accept what I have just said, you could still say why
bother having three namespaces today? Why not just wait until the
modularization stuff is complete? And I can only repeat that there is
still the issue of legacy documents. Converting the mass of HTML we
have, to nice XML requires going via XHTML, and you may need to know
which flavour of HTML 4.0 you came from. Imagine for example, writing an
application that took a load of web pages of football results or phone
lists, and wanted to convert them to XML files of the core data, with
accompanying XSL files that when applied to the this XML data bring you
back to the original HTML that you just broke down. (A pretty nifty
app!) In that situation you would probably want to know what variant you
came from.

As I said in a previous message, if you think of what I just described
as tidyHTML, and the modularised stuff as futureHTML then it's all
pretty straightforward. It just so happens that tidyHTML has been called
XHTML 1.0 and futureHTML is also called XHTML ... and currently stands
at, er ... version 1.0. (And also to get some good PR, I think the W3C
pushed the futureHTML aspect of XHTML, which if we're honest is not even
out of the stalls yet.)

Regards,

Mark

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)