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: infinite depth to namespaces



On 31 Aug 2001 11:46:20 -0700, Fuchs, Matthew wrote:
> Right.  Which is why, if you're going to use local elements in a schema, you
> should make them unqualified, as that works best with existing software.
> See my response to Rick.

Uh, no.  I don't see instance documents as having anything inherent to
do with a "schema" context.  My best practices and existing software
deal with XML 1.0 and Namepaces in XML, not the extra parts certain
organization have seen fit to pile on top and call "XML Schema".

There are lots of folks who don't deal with W3C XML Schema - or any kind
of schema - at all.  The statement above suggests that you have little
interest in these folks.

I don't expect documents created by W3C XML Schema users to stay
isolated in their own little universes - documents have a tendency to
migrate over years.  Those documents are going to cause problems for the
XML world outside of W3C XML Schema for years to come.

> This also shows that best practices need to evolve.  While "put everything
> in a namespace" was reasonable best practice before the arrival of XSDL, the
> concretization of a notion of "local elements" (I hesitate to call it
> "formalization") - just as the Namespaces rec concretized the notion of
> "global attribute", which hadn't existed syntactically before, although
> people used them - can change what best practices can be.  And best
> practices for local elements is unqualified.

Best practice for XML 1.0+Namespaces is that there isn't any such thing
as a "local element".  There are qualified and unqualified elements, and
maybe you can talk about element context, but there's no "local element"
in a lot of people's vocabularies.

The arrival of XSDL isn't quite as earth-shattering an event as some
folks seem to find it.

Simon St.Laurent
http://simonstl.com