xml-dev - Re: Next Round

[Tyler Baker <tyler@infinet.com>]

david@megginson.com wrote:

> Tyler Baker writes:
>
>  > First, we will need to define a new type, namely Name.
>  >
>  > public interface Name {
>  >   String getPrefix();
>  >   String getLocalName();
>  >   String getQualifiedName();
>  >   String getNamespace();
>  >   String getExpandedName();
>  >   Name clone();
>  > }
>
> [...]
>
> I proposed something like this early on as well, but have since backed
> away from it.  I like to keep SAX very dumb and low level, so that
> other APIs (like SAXON or MDSAX) can build on top of it with little
> constraint.

I agree totally with you except for the fact that namespaces automatically
makes XML no longer dumb or necessarily low-level.  The main reason for
this suggestion is that the alternative is for applications to manage
namespace processing themselves or else dump some filter on top which may
add major inefficiencies.  Before making any judgement on this regarding
MDSAX or SAXON, I would ask Michael Kay and Bill la Forge what they think
about a Name type and anyone else who has written some higher-level API's
for XML (this includes DOM implementors).  I know that with an XSL
Processor I have been working on which has SAX support for building the
stylesheet tree, a specific Name type would help out alot in implementing
the "Namespaces in XML" parts of constructing the result tree.

Another major reason for doing Names this way is that for objects (perhaps
beans) may have no global idea of what the current namespace they are to
be applied to.  If you attach a Name type, when spitting out XML you can
automatically construct the namespace nodes (attribute namespace
declarations) as needed (note, I am not speaking about XSL right now).  Of
course you can do all of this on top of SAX, but it may be inefficient and
certainly very much unnatural for developers using SAX in applications to
handle.  "Namespaces in XML" is complicated enough as it is so I feel that
making an effort at simplifying things as much as possible for the end
user would do a great deal of justice in presenting something so
complicated to handle in a simple way.  Last but not least, for DOM
implementations that are built with SAX and may have proprietary
namespaces support (don't know when or if the DOM will have any kind of
namespace awareness in the future) it would really help these folks out a
lot.  Docuverse SDK would be just one off the top of my head.

The point here is that pretty much anyone who uses "Namespaces in XML"
(which I feel will likely be less than 1% of the XML user community in the
future if even that high) will have to deal with the myriad of problems
that "Namespaces in XML" creates one way or another.  I would prefer to
try and remove as much complexity from the application developer as
possible so that using "Namespaces in XML" will not be too much of a pain
(most people I don't think will accept the toothache and instead stay away
from "Namespaces in XML" altogether).

Tyler


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