- From: Mark Feblowitz <mfeblowitz@frictionless.com>
- Date: Wed, 24 Jul 2002 13:51:40 -0400
- 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. Mark -----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" /> and: <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 namespaces? Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Wednesday, 24 July 2002 13:52:12 UTC