[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX Filters for Namespace Processing

• From: Tom Bradford <bradford@d...>
• To: Richard Tobin <richard@c...>
• Date: Sat, 04 Aug 2001 19:52:24 -0700

Richard Tobin wrote:
> >Do you understand how this statement completely contradicts the original
> >intent of XML?
> 
> Hang on, consider the context of this.  The thing that's "hazardous"
> is copying a fragment of XML from one place to another, and the
> sense in which it's hazardous is that it may become impossible to
> identify what vocabulary the elements belong too.

The context of the original issue was related to namespaces, but the
statement was a generalization of text processing of XML based on past
threads, and not in reference to anything in particular.  And so my
comment still stands.  For the past couple of years, we've been having
to deal with all sorts of exceptions that have been introduced as a
result of the layering of technologies onto XML.  At this point, we're
very nearly to a stage where there are just as many exceptions to the
original rules as there are norms.  

> Now this was always true, even before namespaces.  In fact, it was
> *more* true before namespaces, because there was nothing you could do
> about a name clash short of renaming the elements.  Namespaces have
> relieved this somewhat, in that you can bind prefixes locally to

While it was true before namespaces, the consequences of hand editing a
document weren't as damaging as in the case of namespaces.  I'm not
against namespaces, I'm against the way that they are presented, and the
way that they are conveniently ignored redefined when it comes to
situations that don't quite fit in line with the original motivation or
domain of namespaces.

> preserve their meaning.  A simple cut-and-paste can't do this,
> because you have to insert namespace attributes, but XSLT does it,
> XInclude will do it, and a namespace-aware editor can do it.

Exactly... Tools.  It's no longer easily human editable, and no longer
easily human readable.  But these were some of the promises of XML.  A
few years ago, we sold a bill of goods to the IT community.  We've
delivered on it, but we've also introduced many unforeseen maintenance
costs, that the buyers never planned on, and would have caused them to
think twice, had they known in advance.  In that sense, the W3C isn't
much better than a used car dealer.

> them.  If you want to use elements whose vocabularies are determined
> by their parents, you just can't put such elements from different
> vocabularies inside the same parent.  

It's even worse with XML Schemas because an element isn't just valid in
the context of its parent.  Potentially the entire tree up to the root
is the validating context.  In this case, based on the schema, one
element named 'blah' might mean something completely different from
another element named 'blah', even if they have the exact same parent
element, and even if they're in the same namespace.  Quite the exception
from DTDs, eh?  

-- Tom

• References:
  • Re: SAX Filters for Namespace Processing
    • From: Richard Tobin <richard@c...>

• Prev by Date: Re: ANN: SAX Filters for Namespace Processing
• Next by Date: Re: ANN: SAX Filters for Namespace Processing
• Previous by thread: Re: SAX Filters for Namespace Processing
• Next by thread: RE: SAX Filters for Namespace Processing
• Index(es):
  • Date
  • Thread