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

RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceP

• From: "Fuchs, Matthew" <matthew.fuchs@c...>
• To: 'Ronald Bourret' <rpbourret@r...>
• Date: Tue, 21 Aug 2001 11:33:19 -0700

Ron,

> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@r...]
> Sent: Tuesday, August 21, 2001 1:36 AM
> To: Fuchs, Matthew
> Cc: 'Kohsuke KAWAGUCHI'; Xml-Dev
> Subject: Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> NamespaceProcessing)
> 
> 
> "Fuchs, Matthew" wrote:
> 
> >  Please also note that locally scoped
> > elements are _not_ just elements whose declarations occur in a funny
> > location in a schema. They actually _are_ a different beast 
> from global
> > elements and _must_ be treated as such.  I don't think that 
> the W3C Schema
> > WG ever really came to grip with this fact, given the 
> inadequate support
> > provided for them by spec's component model.
> 
> I think this pretty much sums up the objections to local elements --
> they are a different beast. They don't play well with namespaces and
> they certainly break one of my fundamental assumptions about XML --
> namely that an element's name at least tells you what a piece 
> of data is
> (even if you do need context to determine who that data belongs to).
> This reduces data portability, although the more I think about it,
> complete data portability probably doesn't occur often at the 
> individual
> element level anyway.
> 

In considering this, I think we need to separate the _requirement_ (or at
least goal) from the actual design.  The requirement/goal was (as with
namespaces) a mechanism to allow a local name to appear in different
contexts with different types, thereby enabling good Software Engineering
principles like separation of concerns, information hiding, minimizing
dependencies, etc.  Local elements are the means of accomplishing this.
That they don't play well with namespaces is a consequence of the design
finally chosen by the W3C Schema WG.  A different design could work well -
and one of the reasons I backed the current defaults was not just that I
felt they were more upwardly compatible, but because of a somewhat
Wittgensteinian interpretation (from Andrew Layman) of the NS rec, that
anything not in a namespace was outside of the scope of the recommendation -
i.e., one was free to make any statements about them without contravening
the rec because it didn't apply.

If you look at the Formal Description, there's a discussion of normalized
names (now often refered to as NUNs).  These give a unique name to every
definition/declaration in a schema and so can resurrect your "fundamental
assumption" - which I don't disagree with at all.  I've always had a problem
with true anonymity.

> They also complicate processing. SAX applications must keep stack
> information to handle local names, whereas they might (and I emphasize
> might) have avoided this previously. XSLT now has to worry about
> renaming elements to place them in a new context and also has to worry
> about collisions. (Both of these were previously a problem with
> attributes.) There are undoubtedly other things as well, although it's
> not clear if anything is flat-out broken (as opposed to merely more
> complex).
> 

Well, yes and no. If one adopts a more OO style (where one dispatches on
type), then they make things much easier.  The apparent complexity is easily
hidden in the dispatch mechanism.  Currently, where "local" names occur
(i.e., elements that are really only intended to show up in a single content
model), the programmer must maintain the context (stack) by ad hoc means.
Also, if one had access to the NUNs, then local elements would be reflected
by their universal names (just as global ones currently are by their
qualified ones) and you could process as currently.  I have a proposal I'll
post soon to support OO dispatch for SAX and XSLT applications.

> What I can't decide is whether the complexities local element 
> types add
> are worth the benefits they add to serializing object graphs. Put
> another way, I can probably explain element types (as opposed to just
> elements) to my Mom. I don't think I can explain local element types.

I suspect she can understand why - it's the final implemenation that's
complex.

Matthew

• Prev by Date: RE: Including multiple schemas - duplicate name errors
• Next by Date: RE: Namespaces, schemas, Simon's filters.
• Previous by thread: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceProcessing)
• Next by thread: RE: Missing F's (used to be XML.COM: How I Learned to Love daBomb)
• Index(es):
  • Date
  • Thread