Re: infinite depth to namespaces

[Peter Piatko <piatko@research.telcordia.com>]

I am probably way behind on this thread, but here's my two bits ...

In XML Schema local elements can be avoided by manually separating them out
into their own namespaces.

<aside>The other option, possibly, is to use <xsd:choice> in some cases,
which boils down to having multiple declarations for an element.  There may
be nothing wrong with doing this; it just shoves the problem to another
domain (e.g. a context aware processor must decide whether a particular
choice is valid).</aside>

However, I think this task could quickly become onerous with a large
vocabulary.  The fact that people haven't hit this wall kind of surprises
me.  Am I missing something (probably, yes :)?

Local elements have the added advantage that their intended use is made
abundantly clear (I am talking conceptually here ... IMHO, the actual syntax
of the XML Schema language doesn't make it so clear that a local element is
even being declared).  By manually putting local elements into their own
separate namespace, this connection is broken.

OTOH, I gather that support for local elements just isn't there yet,
syntactically or otherwise.  That would be enough to make me think twice
about using them.  But *conceptually* I feel local elements are ok.

I think Matt was trying to lead us to a sort of compromise whereby local
elements were placed in their own namespace, a namespace whose identifier
was generated by some yet-to-be-defined mechanism.  This extends some hope
of interoperability with non-XML Schema-aware processors.

Thanks,

Peter

----- Original Message -----
From: "Leigh Dodds" <ldodds@ingenta.com>
To: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>; "'Simon St.Laurent'"
<simonstl@simonstl.com>
Cc: <xml-dev@lists.xml.org>
Sent: Saturday, September 01, 2001 5:34 AM
Subject: RE: infinite depth to namespaces


>
> > -----Original Message-----
> > From: Fuchs, Matthew [mailto:matthew.fuchs@commerceone.com]
> > Sent: 31 August 2001 19:46
> > To: 'Simon St.Laurent'
> > Cc: xml-dev@lists.xml.org
> > Subject: RE: infinite depth to namespaces
>
> [...]
>
> > 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.
>
> There's an implication here that the 'concretization' of local elements
was
> an obvious and good step forward.
>
> If it were then the best practice you suggest is probably the best
> approach. But despite the massive amount of postings on this subject
> I've still to see (or have I missed something along the way) a
> strong justification for this new 'feature'. And others have argued that
> there
> are alternatives to local elements, using existing techniques.
>
> Acknowledging the TIMTOWTDI / TSBOOWTDI divide, and that
> this somewhat academic argument is unlikely to be resolved to
> anyone's satisfaction, surely best practice is to avoid their
> use. The justification being human factors, or the principle of
> least surprise.
>
> There seems to be no loss in functionality in this approach, and
> I'd argue that this works _best_ with current software, of which
> only a small portion is W3C Schema aware.
>
> There's a quote about unnecessary multiplication of entities
> which is pertinent.
>
> L.
>
>
> --
> Leigh Dodds, Research Group, ingenta | "Pluralitas non est ponenda
> http://weblogs.userland.com/eclectic |    sine necessitate"
> http://www.xml.com/pub/xmldeviant    |     -- William of Ockham
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>