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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: (more) extensible SAX

[ Lists Home | Date Index | Thread Index ]
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Wed, 06 Dec 2000 02:30:00 +0100

Elliotte Rusty Harold wrote:
> At 4:37 AM +0100 12/5/00, Eric van der Vlist wrote:
> >Instead of:
> >
> >startElement(java.lang.String namespaceURI,
> >       java.lang.String localName,
> >       java.lang.String qName,
> >       Attributes atts)
> >       throws SAXException
> >
> >I would have far preferred to have:
> >
> >startElement(org.xml.sax.StartElement start)
> >         throws SAXException
> >
> I have a real problem with this whole idea. I think it would make the
> API significantly less obvious and harder to learn. The current API
> is (mostly) very straight-forward. There are a strictly limited
> number of classes and interfaces you have to learn before doing real
> work, basically just ContentHandler and XMLReader.  I'm opposed to
> cluttering the API with a lot of extra required classes like
> startElement.

I use to think that simplicity is a very subjective concept ;=) ... and
I am not convinced that adding redundant parameters in method calls
makes an API easier to learn.

> I am also not convinced by the cases you cite where you think the API
> will have to change in the future. For instance, I don't see why
> xml:base or xml:lang will require any method signatures to change.
> Both can be handled very straightforwardly now by those limited
> number of programs that need to handle them, simply by storing a
> stack of the current bases or languages encountered as startElement()
> and endElement() are called.

I am not convinced either that xml:base or xml:lang are concerning a
limited number of applications. Anyway, that wasn't the main point in my
email and I can try to give other examples.

New specifications like W3C XML Schema or XInclude are introducing
transformations in the infoset that may be implemented as SAX filters.

However, with the current SAX 2 API, there isn't much room to keep
information about the original infoset and this information may be
useful for some applications.

In the same area, such an extension mechanism could be useful to give
information about the schema (W3C or any other) related to the current
element or attribute like DOM Level 3 seems to be heading to.

> --
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+

See you at XML 2000
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com


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

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