xml-dev - Re: General SAX2 Observations

[David Brownell <david-b@pacbell.net>]

General SAX2 Observations> 1) The feature mechanism is busted wrt the two
namespace-related features.

Agreed.  As the simplest conceptual issue, two flags define four states ...
one is declared illegal, and there are really only two useful models for
working with XML documents (XML, or NS).  Why are three  models provided?


> Ideally, the ContentHandler would have the following method:
>     public abstract int getNamespaceSupport();

I'm not sure I could limit it to that particular feature.  Wouldn't it be
important to handle others too?  There's a slippery slope there; if
the datastream must be namespace-legal to some degree, why wouldn't it
be as appropriate to offer a guarantee that it be schema-du-jour-valid?


> that would return one of the following three values:
>     static final int NAMESPACES_ONLY = 0;
>     static final int RAW_NAMES_ONLY = 1;
>     static final int RAW_NAMES_PLUS_NAMESPACES = 2;

Actually, I'd really go for Elliotte's suggestion here:  don't introduce
a new term "Raw" names.  If a new term is needed, I'd say "XML" Names, to
highlight the fact that the namespaces spec makes certain XML 1.0 documents
become illegal ... else, use the "QName" from the namespace spec.

And again, having three modes seems like it's too much.  My preference
would be to get rid of "namespaces only".  As has been established in
other discussions on this list, qualified names can and do appear in more
locations in a document than an XML processor may be aware of.  It's not
healthy to _encourage_ the needless discarding of prefix information.


Re C/C++ mappings you proposed the following guidelines:

> a) Hoist all shared types into pure abstract base classes or flat
structures.
> b) Never allow class-based references or instances to be shared across
>    component boundaries. This includes std::string!
> c) Understand that RTTI doesn't work across component boundaries.
> d) Understand that exception handling doesn't work across component
boundaries.
> e) Understand the tradeoffs of supporting both char and wchar_t.
> f) Understand that malloc/free new/delete don't work across component
boundaries.

Seems like all those references to "component boundaries" would be specific
to some particular compilation environments.  Which of those guidelines
come from limitations in current C++ environments, vs from the C++ standard?
Which come from _intermixing_ C/C++ components with others (which has never
been fully standardized)?

Note that I'm not disagreeing that some such guidelines _may_ be needed; I'm
concerned that API designs not be torqued to suit particular compilers,
since
some of them have severe standards conformance problems.

- Dave



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************