[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML APIs - What's next?

• To: "Mike Champion" <mc@x...>,<xml-dev@l...>
• Subject: RE: XML APIs - What's next?
• From: "Manos Batsis" <m.batsis@b...>
• Date: Mon, 5 Aug 2002 22:08:06 +0300
• Thread-index: AcI8rR7vbyzyK8A6R5KBjzXmqm0HawAAoJfZ
• Thread-topic: XML APIs - What's next?

<Mike.Champion>
So, starting with the most basic assumptions, is the idea of a
vendor-neutral read/write XML API still viable?  I *think* most
besides our benevolent protectors in Redmond would agree,
as long as we're talking about a foundation layer rather than
One True Standard.  How about language neutrality?  Could a DOM-like
API with a language binding model that allowed NodeLists, etc. to
be mapped onto whatever language-specific interface makes the
most sense find some traction?  Finally, who would use such a
beast?  Is the XML InfoSet just too low-level to bother trying to
expose to ordinary users?  Do most people want to use a data binding tool to
hide the XML as a serialization format, or would a clean API (e.g.,
that was integrated with XPath and XSLT, hid bizarre syntax such as
CDATA sections, and had a sensible model of how text was related
to elements) find some customers?
</Mike.Champion>

IMHO we need an API that

* Works initially at the low-level
* Is attached strictly to the infoset
* Can be used to build high-level APIs in the form of libraries for specific doctypes, without the need of XSD validation. These highlevel views should be build upon the sructure of XML with no prior attempt to define semantics over the sructure (with rare exceptions i.e. the xml namespace)
* Attempts to provide an umbrella for different modes of processing. Those modes can be random access or streaming, or anything dynamic in between or even new.
* Allows new ways of memory management. An in-memory build/collapse fragments without deletion of nodes is a pain in attempts that are mostly based on DOM+SAX and something databases are not capable to fill in for us. We need a moving view of an endless document whose parts can be changed by any proccess when out-of-scope, and by the API when in-scope.

Just my 0.25.

Manos

• Prev by Date: RE: XML APIs - What's next?
• Next by Date: Re: Re: maps
• Previous by thread: [announce] Lucid XML Server Publisher 1.0b1 released
• Next by thread: Quick, Easy Namespace Question
• Index(es):
  • Date
  • Thread