W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2002

RE: restriction question

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Wed, 24 Jul 2002 13:51:40 -0400
Message-ID: <4DBDB4044ABED31183C000508BA0E97F040ABE16@fcpostal.frictionless.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>, xmlschema-dev@w3.org
Cc: "David Connelly (E-mail)" <dconnelly@openapplications.org>, "Duane Krahn (E-mail)" <duane.krahn@irista.com>, "Satish Ramanathan (E-mail)" <Satish.Ramanathan@mro.com>, "Andrew Warren (E-mail)" <awarren@openapplications.org>, "Kurt A Kanaskie (Kurt) (E-mail)" <kkanaskie@lucent.com>, Mark Feblowitz <mfeblowitz@frictionless.com>, "Michael Rowell (E-mail)" <mrowell@openapplications.org>

Yes, Jeni - 

And I'm afraid I started that thread, based on a need to practically manage
both an evolving interchange specification, OAGIS, and its industry-specific
and company/organization-specific overlay layers. 

We do exactly what you're discussing, and achieve it in separate, overlaid
namespaces. It is only possible because, for this and other reasons, we have
sworn off complexType derivation by restriction. 

Our members are able to create their own extensions to our core
specification, yet do so in separate namespaces. This is important for both
name disambiguation and to protect the integrity of our core specification. 

It is not practical, given the multiple layers that we're already seeing,
for us to use the noNamespace trick. And I don't think anything needs to be
done with include/redefine and namespaces - that would really help. It would
be quite useful to have the implicit substitution that you suggest. As it
stands, we have had to back away from some of our more desirable
metamodeling, since it requires cross-namespace derivation by restriction. 

I don't see resolving this as being the one thing that would get us to use
derivation by restriction, though. The need to separate derivation steps
would still remain, as would the highly impractical problem of replicated
(large) content models. 

But it would be goodness to find a way for ns2:foo and its content to be
validly derivable by restriction from ns1:foo.


 -----Original Message-----
From: 	Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent:	Wednesday, July 24, 2002 6:15 AM
To:	xmlschema-dev@w3.org
Cc:	Mark Feblowitz
Subject:	Re: restriction question

Mark Feblowitz wrote:
> Yes - and [the rules governing derivation by restriction in XML
> Schema] simply kills any notion of having layered namespaces
> (defining concepts in ns1 and restricting them in ns2).

There's also been a bit of discussion recently on XML-Dev about
identifying the versions of markup languages through namespaces with
this same notion of "layered namespaces".

"Layered namespaces" occur when there is a recognisable relationship
between two different namespaces such that elements declared in one
namespace are automatically recognised as also being part of another
namespace and applications accept elements from a later version of the
namespace in place of those from an earlier version of the namespace,
for example.

I've previously considered namespaces as being standalone, unrelated
to each other, and regarded the elements:

  <foo xmlns="http://www.example.com/ns1" />


  <foo xmlns="http://www.example.com/ns2" />

as completely different elements rather than "really the same, just
with different namespaces". I still feel that this is the right way of
thinking about it, based on the way that namespaces are defined in
"Namespaces in XML" and used in various other Recommendations, and
that the idea of layering namespaces is misguided, but given that
there seem to be several people whose opinion differs, perhaps I'm
being too dogmatic.

You can already kinda layer namespaces in XML Schema, but only if the
base namespace is no namespace -- if you include a schema with no
target namespace into a schema with a target namespace, then the
components from the included schema are adopted into the target
namespace, but you can't do the same kind of thing when the other
schema does have a (different) target namespace namespace.

So I wonder if the same kind of thing could be done with schemas in
other target namespaces; in other words whether the constraint that
xs:include and xs:redefine must refer to schemas in the same target
namespace (or no namespace) should be lifted.

Alternatively, I wonder whether there could be some kind of "implicit
substitution group" for locally declared elements, such that, in a
restriction, an element in one namespace could be substituted for an
element with the same local name in another namespace.

Any thoughts about whether either of these options would be feasible,
and whether they'd meet the requirements of those who want to layer



Jeni Tennison
Received on Wednesday, 24 July 2002 13:52:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC