[
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
>http://www.itworld.com/nl/xml_prac/04182002/
>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/ |
+----------------------------------+---------------------------------+
|
