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

SAX: two alternatives for namespaces

• From: David Megginson <david@m...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Tue, 28 Jul 1998 21:47:43 -0400

Background: 

  Simple XML 1.0 names have only a single part, and are unique only
  within a document; the namespaces spec currently under development
  defines globally-unique names consisting of two parts: a (possibly
  null) URI part and a base part.

Question:

  What changes to SAX 1.0 are required to support two-part names?


After reading the follow-ups to my last posting, surviving far too
many late WG meetings, and considering the problem during a few long,
early morning runs, I can see only two reasonable alternatives for
adding namespaces to SAX.

I would like to hear what everyone -- especially, but not exclusively
SAX parser and application writers -- thinks of these two
alternatives:


1. Concatentation

  Use a single Java String (or C++ wstring, etc.) to represent a
  two-part name; select a non-XML character to use as the separator.

  Advantages:
  - requires no modification to SAX 1.0

  Disadvantages:
  - places additional burden on applications
  - makes equality testing tricky
  - may produce unexpected results with applications that assume only
    traditional one-part names (especially normalisers)


2. New Interface

  Create a new SAX interface to represent a two-part name:

    public interface Name
    {
      public void setURIPart (String uri);
      public String getURIPart ();
      public void setBasePart (String base);
      public String getBasePart ();
      public boolean equals (Name name);
      public Name clone ();
    }

  Use this interface consistently throughout SAX for all XML 1.0 names
  (not just those covered by the namespaces spec).  Modifications
  would be required to the DTDHandler, DocumentHandler, and
  AttributeList interfaces and to the HandlerBase and
  AttributeListImpl classes.

  Advantages:
  - provides a clean and powerful implementation
  - easily extensible: could add other information (such as the prefix
    used) in the future
  - provides easy and separate access to the URI part and the base
    part of a name
 
  Disadvantages:
  - another bloody interface
  - backwards-incompatible with SAX 1.0; all software would have to
    change


Of course, we should finalise nothing until the namespaces spec
becomes a recommendation.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: SAX: two alternatives for namespaces
    • From: John Cowan <cowan@l...>
  • Re: SAX: two alternatives for namespaces
    • From: Chris Hubick <maillist@c...>

• Prev by Date: Could you forward this? [from Jon Bosak]
• Next by Date: New release of XML for Java: 1.0.4
• Previous by thread: Could you forward this? [from Jon Bosak]
• Next by thread: Re: SAX: two alternatives for namespaces
• Index(es):
  • Date
  • Thread