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


Help: OASIS Mailing Lists Help | MarkMail Help



   [xml-dev] re: XML SIG 17 September: Elliotte Rusty Harold onWhat's Wro

[ Lists Home | Date Index | Thread Index ]

At 9:46 AM +0100 9/16/02, Sean McGrath wrote:

>>or maybe in many cases you could do away with the API's altogether?
>Yes. There is, it seems to me, as potent a bifurcation between API-centric
>XML and notation-centric XML as there is between data heads
>and doc heads. There two are related, perhaps two sides of the same 
>coin, I don't
>really have a handle on it but this article 
>gives a flavour of the itch I'm trying to scratch.

I think even Walter would agree that a good XML API can be useful for 
locally processing a particular XML document. :-) The question is not 
so much whether to use an API, but which API to use and which level 
it exposes. The article Sean wrote appears to be complaining about an 
API that was running at too high a level. He needed something lower, 
closer to the raw sockets. It's not clear if XML APIs were really an 
issue for him.

It also seems from his description that the the system he was dealing 
with may have been relying on behavior not endorsed by the HTTP 
standard. The HTTP 1.0 spec states, "The order in which header fields 
are received is not significant." and "Multiple HTTP-header fields 
with the same field-name may be present in a message if and only if 
the entire field-value for that header field is defined as a 
comma-separated list [i.e., #(values)]. It must be possible to 
combine the multiple header fields into one "field-name: field-value" 
pair, without changing the semantics of the message, by appending 
each subsequent field-value to the first, each separated by a comma." 
HTTP 1.1 does make it a little clearer that header field order may 
matter, but only for the case of header fields with the same name, 
and these can always be replaced by a single header field with a 
comma separated value in conformant uses.

What I will propose tomorrow is a very low level API. It focuses on 
namespace well-formed XML. It can parse any namespace well-formed XML 
and generate only namespace well-formed XML. Unlike some other APIs, 
it does not attempt to layer an additional view on top of XML. It 
does not try to make XML look like a database table, a method call, 
an object, or something else that is not XML. It is an XML API, 
nothing more, nothing less.

I do limit the syntactic structures that can be interpreted in 
different ways. For instance, it will not allow users to distinguish 
between CDATA sections and the same text encoded in other than a 
CDATA section. However, the structures it exposes are those defined 
in XML itself: elements, attributes, processing instructions, etc. 
I'm not sure if this will bother Walter or not. I guess I'll find out 
tomorrow. :-)

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


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

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