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: Namespace: what's the correct usage?

----- Original Message -----
From: "Francis Norton" <francis@redrice.com>
To: "Martin Gudgin" <marting@develop.com>
Sent: Sunday, May 20, 2001 5:03 PM
Subject: Re: Namespace: what's the correct usage?

> [bought back on-list by permission!]
> Martin Gudgin wrote:
> >
> FN Wrote:
> > >
> > > This idiom is supported by XML Schema elementFormDefault="unqualified"
> > > but to me it seems to redefine namespaces rather radically. There will
> > > be complications when processing documents containing data from
> > > "namespaces" with clashing unqualified element names.
> >
> > Why? Surely at the point you come across the qualified element you
> > out whether you recognise it or not. If not, then don't process that
> > and its descendants, skip to the next sibling.
> >
> Aha - but I have to explain that I am a fairly hardcore XSLT / XPath
> user. Declarative, not sequential, but you're already having that
> conversation with Jeni and David ...

Yes, as noted earlier in this thread the declarative style does have bearing
on the issue.

> > >
> > > I suspect that it might be a good rule of thumb not to combine
> > > elementFormDefault="unqualified" with xsd:any.
> >
> > I'm not sure why you think that. xsd:any takes a namespace attribue that
> > allows the schema author to control what namespace(s) the replacement
> > element(s) may come from. e.g. <xsd:any namespace='urn:x1' /> would only
> > allow an element whose namespace name was 'urn:x1'. You *could* allow
> > unqualified elements by saying <xsd:any namespace='##local' /> or
> > /> ( which allows absolutely anything ). I agree that you would need to
> > careful in this latter situation.
> >
> Because <xsd:any namespace='urn:x1' /> might also be
> elementFormDefault="unqualified" with local no-namespace elements, so
> *all* the xsd:any options could introduce element name clashes in
> no-namespace.

But a such a wildcard would *only* be satisified by a qualified element in
the correct namespace... Unqualified elements from a schema with the same
value for the targetNamespace attribute would *not* satisfy such a

> As a motivating example - I wrote an extractor to assemble a Schematron
> schema from constraints embedded in XML Schema annotation/application
> elements. Using "proper" namespace qualification gives scalability -
> others can do what I've done without increasing conflict or complexity.
> If I'd used the unqualified form I'd have to trust that no-one else did.
> Or that if they did, that I was in a political position to make them
> back off ... not really my idea of good practice.

I'm not sure I understand the point you are making here...