RE: SAX Filters for Namespace Processing

[Jonathan Borden <jborden@mediaone.net>]

Tom,
...
 I don't know many other 'users' who are also producing
> specifications for things such as resource definitions, access control,
> etc.  I am also an exception to the rule, except that I am involved in a
> project where the needs of my users are something I deal with
> constantly.  For quite some time, dbXML didn't have support for XPath
> namespaces, and it wasn't requested until a few weeks ago, and by only
> two people out of quite a few.

I am certainly sympathetic to your viewpoint, and strongly agree that we
need to keep XML as simple as possible. As we say "code talks".

On the other hand, I also think that XML Namespaces has gotten alot of
undeserved flak, primarily because it introduces a few new ways to shoot
yourself in the foot, but on the other hand, the resultant hole in the foot
is no larger than can be made with e.g. enternal parsed entities etc.

The main thing that XML Namespaces provide is not a simple partitioning of
names (booring!) rather a mechanism _by which_ XML can be better integrated
with the web (via URIs). Of course XML Namespaces makes no mention of this
but of course that is the whole point of RDDL, and so if XML namespace names
are seen and used as _URIs_ not merely unique names, we have something
that's actually useful. Of course the XML 1.0 link to the web is via a
system identifier and external entities (choke!) so I see namespaces
actually as an overall simplification rather than added complexity.


>
> > For example: XSLT. Hard to use it without using namespaces, eh?
>
> An unfortunate biproduct of defining XSLT as an XML grammar.  As an XML
> grammar, could it have been done without namespaces?  Sure.  And again,
> I'm not against namespaces, I'm against their abuse.  I don't really
> like the mechanism itself, but a namespacing system is necessary for
> some cases.

Sure, and of course namespaces and XSLT might have been implemented
differently. But see above. Similarly XPath might have been implemented
differently but that's a done deal, and (IMHO) you are best to implement it
_as is_ in all its glory :-)

As a -user- of XPath, I didn't expect that I'd have to request namespace
support in an implementation, just as we might argue that English is not
designed in a logical fashion, I happen to know it and aren't sure that I'd
ever getting around to learning or using the 'fixed' version.

>
> > Shrug. The EDI folks are looking pretty closely at XML.
>
> Yes, I know.  I was one of those EDI users.  The simpicity of XML is
> what drew me to it.

And you are exactly correct that the _mere use_ of XML does not in any way
ensure that the system will be properly designed. Certainly something of
arbitrary complexity ... even monstrosities ... might be built on binary
logic, that doesn't mean binary logic is not itself a good thing.

>
> > Shrug. I suspect that alot of carpentry _businesses_ will be
> using XML in
> > some form or another (hopefully unbeknownst to them!!) in
> several years or
> > so.
>
> That's if XML survives the backlash that will definitely come if the
> bloat continues at its current rate.
>

Specs come and go. I think XML will succeed in the long term, I don't think
all of the XML related specs will succeed. I'm not sure that the so called
XML 2.0 will ever get done correctly, and if done incorrectly wouldn't bet
that it will come into widespread use (barring of course something like XML
blueberry which when Khmer becomes the dominant language of Earth something
in this later millenium, might actually become quite useful :-)

So in generally while there is alot of yada yada yada discussion related to
XML it is something worth getting right.

-Jonathan