OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XHTML survival rate?

[ Lists Home | Date Index | Thread Index ]

From: "Eric van der Vlist" <vdv@dyomedea.com>
> I think we have to face it: XML or not, pages on the web are what they 
> are, we have no power to enforce any format or specification and will 
> have to adapt our tools and relax our parsers if we don't want to 
> restrict ourselves to accessing an insignificant proportion of the web.
The shortcoming is not XHTML but XML.

Draconian error-handling is appropriate for formal data, but unworkable
for casual documents where the user would prefer anything prints rather
than nothing prints.   We are starting to see HTML-to-SAX parsers,
and I hope this will eventually lead to some alternative to XML for
casual use*, perhaps even if specified as an error-handling policy.

But there is another issue lurking: scoping. Xml:lang, xml:space and 
xmlns are all scoped in effect; there are (last time I checked)
SVG attributes that had scoped effect. But these kind of attributes
have no support in any schema language: we cannot provide
a schema that tells software "if you copy a branch, bubble down
this attribute too and transport that".  The Fragment Context
Specification approach has not taken off, because it is at the
wrong level, apparantly, and requires too much infrastructure.

So, given that there are attributes that have scope, but we don't
have schema languages which declare that they should be 
propgated nor any tools to do it, it means that that kind of XML
cannot be edited.  

I think this is why we see in XML such an emphasis on transformation 
rather than inclusion or cutting-and-pasting.  The infrastructure is
not their (neither in the specs or in proprietory systems).  There
is now some awareness about this for namespaces (in the recent
discussions about whether namespace scope is itself an information

So I think there are two good reasons why not to expect XHTML
to take over from HTML for casual documents on the WWW:
first because the XML's syntax requirements are too much,
and second because the XML-family of specs has not come
to grips with the general issue of scoping and its relationship
to editing.  

Rick Jelliffe

* For example, allowing  <aaa bbb=ccc ddd=eee>
and allowing  </x></y></z> to be replaced by simple </z> 
or "&" and "<" in data, automatically correcting
name capitalization, and sticking in namespace declarations
and xml:space declarations as required. This would not be
as slack as HTML, but might make the lions share of
conservative HTML documents acceptable as XHTML.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS