OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespaceProcessing)

"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.

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

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.

-- Ron