[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: why distinctions within XHTML?

• From: "Simon St.Laurent" <simonstl@s...>
• To: Mark Birbeck <Mark.Birbeck@i...>, XML-Dev Mailing list <xml-dev@i...>
• Date: Mon, 30 Aug 1999 22:03:14 -0400

At 09:26 PM 8/30/99 +0100, Mark Birbeck wrote:
>Simon - as you are, I am "outside looking in", and you're right it can
>be frustrating.

Frustrating?  I thought it was pure fun.  Oh yeah - just kidding.

>However, my reason for making this assumption stems from
>the following flow:
>
> 1. The biggest barrier to the uptake of XML will not be the
>    popularity or competence of W3C members (just kidding)
>    but the ability to convert legacy data.
> 2. The easiest way to handle legacy data is to convert it to
>    some simple XML, and then take advantage of XML techniques
>    to make it 'nicer'.
> 3. Most legacy data either exists in, or can be easily converted
>    to, HTML. (It sits behind web servers.)
> 4. The quickest initial transformation then, is to get HTML into
>    an XML format that looks pretty much like HTML.
> 5. This can then be tidied up into more meaningful tagged data
>    (one of the goals of XML lest we forget!).
> 6. There are three variants of HTML 4.0 so we need three variants
>    of 'HTML 4.0 as XML' (let's call it XHTML).
> 7. XHTML will be around for a little while in these variants as
>    browsers catch up with this evolution.
> 8. Eventually these variants will give way to a number of modules
>    that handle the different features of HTML, such as a code
>    module, a table module, an image module, and so on.
> 9. Once 'pure' XML documents are being sent to browsers then we
>    will want to mix and match other XML data with the display
>    information that is XHTML. This may mean putting XHTML inside
>    other documents, or other documents inside XHTML.
>10. Current DTDs cannot handle this, but XML Schema type solutions
>    will be able to.
>11. In the short-term we therefore need a schema and a DTD for each
>    variant of XHTML.
>12. But in the long run we will have schemas for each module.

In substance, I like this flow.  Unfortunately, this isn't what's said in
the W3C's PR - and moving from 7-9 seems like a much more complex project
than you suggest, made much more complicated by the use of three namespaces
(indeed, the existence of three variants).  10 and 11 feel like significant
barriers rather than steps.

#12 sounds great, and I thought that was the direction way back at the
beginning of this - I really wonder why the W3C is starting out by
recreating 3 variants of a monolith.

However, it is not ours to wonder why...

Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • RE: why distinctions within XHTML?
    • From: Mark Birbeck <Mark.Birbeck@i...>

• Prev by Date: Self interest is the dominant interest in pushing complexity - creates barriers to entry (3 namespaces in XHTML)
• Next by Date: Searching XML
• Previous by thread: Self interest is the dominant interest in pushing complexity - creates barriers to entry (3 namespaces in XHTML)
• Next by thread: Re: why distinctions within XHTML?
• Index(es):
  • Date
  • Thread