Self interest is the dominant interest in pushing complexity - creates barriers to entry (3 namespaces in XHTML)

[Trevor Croll]

My observation:-
There is a lot of self interest running in this World Wide Web Consortium.
(just look at membership fees)
Staying out in front requires the resources and position to up the barriers
of entry for the opposition.
I would suggest there is potential conflict in self interest in three
namespaces for XHTML. It will make it much more difficult for smaller and
late arrivals to "conquer" to understand and to produce XHTML applications
that compete with those who dominate in this market place.

There is a self interest in producing complexity and I would suggest that
this is part of the problem with the W3C.

>  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.
>
> Note that unless you are mixing documents you do not need to use XHTML
> anyway, unless you plan to store the document in a system that requires
> the document to be validated. You can *produce* XHTML from your XSL
> transformations, but who is going to check it? No current browser is.
>
> VALIDITY TODAY
> So for me, the validity issue *for today* comes when I want to take
> legacy data and make it more meaningful (as per point 5, above). Say I
> have a web page from a client's intranet that has a list of all their
> offices, and I want to convert that to XML. For example, I want to go
> from:
>
> <TABLE>
>     <TR><TD>Office 1</TD><TD>London</TD></TR>
>     <TR><TD>Office 2</TD><TD>Birmingham</TD></TR>
>     <TR><TD>Office 3</TD><TD>Glasgow</TD></TR>
> </TABLE>
>
> to:
>
> <Offices>
>     <Office>
>         <Name>Office 1</Name>
>         <City>London</City>
>     </Office>
>     <Office>
>         <Name>Office 2</Name>
>         <City>Birmingham</City>
>     </Office>
>     <Office>
>         <Name>Office 3</Name>
>         <City>Glasgow</City>
>     </Office>
> </Offices>
>
> without using Notepad. The HTML file has to be converted to XHTML,
> validated and then transformed. Each of the following will display in IE
> and Netscape, but would break my final transformation:
>
> <TABLE>
>     <TR><TD>Office 1<TD>London
>     <TR><TD>Office 2<TD>Birmingham
>     <TR><TD>Office 3<TD>Glasgow
> </TABLE>
>
> <TABLE>
>     <TR><TD ALIGN=LEFT>Office 1</TD><TD>London</TD></TR>
>     <TR><TD ALIGN="LEFT">Office 2</TD><TD>Birmingham</TD></TR>
>     <TR><TD>Office 3</TD><TD>Glasgow</TD></TR>
> </TABLE>
>
> but if you automate the process of converting to XHTML, it will map to a
> known 'standard' file.
>
> VALIDITY TOMORROW
> The validity issue *for tomorrow* is the mixing of mark-up from
> different XML-based languages within one document, and still being able
> to check that all is OK.
>



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)