xml-dev - Re: Next Round

["Bill la Forge" <b.laforge@jxml.com>]

My personal experience is that things are ever so much easier when
addressed at the appropriate level. And in particular, replacing a name
string with an object that can be subclassed means that an API can be
extended very cleanly.

This means that it might be sufficient simply to replace tag and attribute names
with objects that hold the name string, and then define an extended interface that
can be used for namespaces.

Again the objection that this is too Java specific? I would say that for non-Java
languages, the base interface should also support an additional method, say
isInstanceOf. Nothing as heavy as the MS IUnknown is needed.

Then to raise again a previous suggestion from Don, we could simply extend the
functionality of the Parser.setDocumentHandler method by checking to see if the
lexical processor interface is implemented. And again, for non-Java languages,
the DocumentHandler interface should implement an isInstanceOf method.

Refining this further, we could have an interface that is only useful for non-Java 
languages:

public interface nonJava
{
    public boolean isInstanceOf(String interfaceName);
}

This then could be the base interface for all SAX interfaces, when not using Java.

(I would NOT want to do this in Java, as the instanceOf operator is very convenient.)

Bill

-----Original Message-----
From: Tyler Baker <tyler@infinet.com>
To: david@megginson.com <david@megginson.com>
Cc: Don Park <donpark@quake.net>; XML Developers' List <xml-dev@ic.ac.uk>
Date: Thursday, January 21, 1999 8:45 AM
Subject: Re: Next Round


>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)
>


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)