xml-dev - XML as disruptive of other Web techonologies

["Simon St.Laurent" <simonstl@simonstl.com>]

For all the talk of XML changing the world, I'm finding more and more that
XML is actually changing the Web technology it's meant to work with.  While
I hope to XML make an impact on the broader world, it might be worth a look
at what XML is doing to the Web itself.

A few examples are probably in order, so I'll look at MIME content-type
identifiers, URIs, HTTP, HTML, and some general security and infrastructure
issues.


MIME types

I've spent a good deal of time working on the latest XML Media Types draft,
and it's quite clear that XML doesn't fit well with the two-part MIME
content types system.  After a lot of discussion, we've settled on a suffix
indicating that MIME types, whatever else they may be, use an XML syntax,
but getting there has been difficult.

XML opens up new (generic) processing possibilities that weren't expected
when MIME was originally created, and trying to integrate those
possibilities with the existing MIME infrastructure is _hard_.

(see http://www.imc.org/ietf-xml-mime/  
http://www.imc.org/draft-murata-xml)


URIs

When URIs first appeared, they (generally) referred to specific resources.
The shift (in terminology, if not so much in practice) from Locators (URLs)
to Identifiers (URIs) made this a bit more abstract, but not nearly as
abstract as the  usage assigned them by the Namespaces in XML spec, which
makes clear that they don't need to point to anything specific.

(see http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt 
http://www.w3.org/TR/REC-xml-names)


HTTP

Related to URIs, and tied in the small battle here last week, is the use of
HTTP as a transport protocol for other protocols - XML-RPC and SOAP.  Some
URIs that purport to be HTTP are now complex listeners and responders, no
longer accepting 'ordinary' HTTP requests and modifying or ignoring the
HTML forms-based GET and POST approaches to transmitting information from
client to server.

(see http://www.rfc-editor.org/rfc/rfc2616.txt
http://www.rfc-editor.org/rfc/rfc2617.txt
http://xmlhack.com/list.php?cat=25)


HTML

The transition from HTML to XHTML is only getting started, but it seems
like the W3C is moving forward with this potentially difficult project full
speed - "HTML is dead, long live XHTML".  On the other hand, it's very
strange to see certain companies clinging to the old HTML approach, as that
odd spam generated in Word 2000 demonstrated.

(see http://www.w3.org/TR/xhtml-roadmap
http://xml.org/archives/xml-dev/2000/05/0111.html)


Security and infrastructure issues

Even apart from the data/instructions separation some claim make SOAP and
its ilk dangerous, XML raises some new issues for both security and scale.
David Megginson's keynote at XTech 2000 demonstrated that XML's reliance on
external resources presents some significant new issues for document
management and security, especially when such resources are shared.  More
recently, Eric van der Vlist noted the potential impact of four HTTP
requests to the W3C's servers every time a strictly conforming XHTML
document passes through a vanilla XML 1.0 validating parser.  While we hope
they're set up for that kind of traffic, this could get interesting - and
more so as XHTML 1.1's modularization work proceeds. (Using public
identifiers to reference local copies of resources may suddenly become more
interesting.)

(see http://www.megginson.com/ugly/index.html
http://www.egroups.com/message/XHTML-L/79)


While I don't think any one of these issues by itelf is a problem, I think
it's reasonable to step back and assess the impact XML is having on these
tools, which once seemed relatively easy to understand.  If XML is indeed
'SGML for the Web', it's changing that Web by making new demands on the
infrastructure.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************