Re: Locator2 is wrong

At 9:38 AM -0700 4/26/04, Jeff Rafter wrote:

>"If an XML decl callback ever found it's way into SAX I'd prefer it would
>be on a new interface not some extension of one. SAX is implemented in
>other languages. Interfaces like Attributes2, Locator2 and EntityResolver2
>which take advantage of polymorphism allowing these new functions to be
>supported without changes to the interfaces which use them are a pain to
>support in C++. How can you safely cast to these interfaces? There are a
>couple features which a user can query which tell whether the parser
>reports Attributes2 (use-attributes2) and Locator2 (use-locator2). I guess
>you can cast to these interfaces if the value of these features are true,
>but how can the parser down-cast your EntityResolver to an
>EntityResolver2? You'd have the same problem with a LexicalHandler2."
>
>I thought this was important to insert into the discussion. My experience
>would lead me to recommend pushing these into the LexicalHandler, as they
>feel like lexical components-- but of course this would be a major backward
>compatability problem so we would need to create a LexicalHandler2. But like
>Michael says, tough in C++. We could land with a new interface name
>altogether; likely set using a property similar to LexicalHandler and
>DeclHandler. However, I always hated that method of setting up interfaces.
>

I simply don't care, nor should anybody else, what effect this design 
decision has on C++ or other languages. DOM is the ultimate proof of 
the damage achieved by attempting to write one API for multiple 
languages. SAX should be the best Java API it can be. The 
C++/Python/C#/Perl communities should design the best APIs they can 
using the native idioms and techniques of their language of choice. 
There is nothing to be gained by limiting SAX to what works for C++, 
and much to be lost.

If Attributes2, Locator2, EntityResolver2, etc. are a pain the 
posterior for C++ programmers, then they can do something else. There 
is simply no reason they need to be limited by the decisions made in 
a Java API. They don't use the same libraries or naming conventions? 
Why should they use the same API? Interoperability is achieved 
through XML syntax, not through the API.
-- 

   Elliotte Rusty Harold
   [email protected]
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
List: sax-devel, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel