- From: Mark Goodhand <mrg@decisionsoft.com>
- Date: Thu, 14 Sep 2006 09:17:51 +0100
- To: xmlschema-dev@w3.org
On 8 Sep 2006, at 16:05, David Ezell wrote: > Both of the following comments seem to have merit, but it's either > unclear how to implement them or why they'd be important in XML as > opposed to OO. > > N.B. when I joined the schema WG I was an OO programmer, and it was > not at all clear to me what was good for OO wouldn't be good for > XML. The reasons this logic really doesn't hold completely are > subtle, not completely self-evident, and therefore unsatisfying. I > offer the following comments realizing that you'll have to buy in > to this idea before you see my answer as anything other than > sandbagging. Hi David, Thanks for your response. It's quite possible that I've got the wrong end of the stick, and that what I'm suggesting is fundamentally opposed to the logic of XML Schema. From what I do know of Schema, I wouldn't be at all surprised if the reasons turn out to be subtle :-) Please find responses to your specific questions within ... > Mark Goodhand wrote: > > I've long found it frustrating that in order to reuse schema > > components, you have to make them global. > > You mentioned that you are frustrated by this fact. Can you > elaborate? Is that databinding doesn't work as you expect, or some > other problem? At one level the frustration stems from the fact that "it just seems Wrong", but this post was motivated by a practical difficulty. We encountered an incompatibility between the XLink schema created by the OASIS CIQ TC, and the XLink schema used by XBRL. Core XBRL schemas relied on the existence of named components in the XLink namespace, which were defined in the XBRL XLink schema, but not the CIQ XLink schema. Arguably, the symbol spaces in the XBRL XLink schema were polluted -- they contained components not mentioned by the XLink spec. The creation of the components was motivated by a perfectly reasonable desire for internal reuse, but this "implementation detail" was exposed on the "public interface" (because the set of named schema components available to other schemas is the same as the set of named schema components available internally). This created the opportunity for other schemas to *rely* on the unofficial components. I believe the CIQ schemas similarly relied on components that weren't mentioned in the XLink spec. If you're interested in further details, let me know. > Many members of the Schema WG believe that you should be able to > create local complex types and reuse them at that scope, assuming > that's what you're requesting. (Note that the schema component > model could allow this construct, but the XML serialization syntax > has no way to express it.) This belief (which I've held at times > and may hold again) is IMO based in the idea of OO scoping. That level of scoping may be useful. I was proposing visibility control at a document level -- e.g. a top-level type that can be reused anywhere within its containing document, but (if marked as 'private') not available for use in any other schemas. > You have to remember that you can't hide data in XML. It's not > that the idea is bad, it's that the two systems are not isomorphic. It's true that XML Schema "source" is more likely to be available than (say) Java source, but 1) Even when you can see source (e.g. in any open source project), the compiler-enforced distinction between implementation and interface is still useful, and 2) As I understand it, XML is just one possible serialisation for XML Schemas -- the Schema spec allows Schemas to be stored in opaque, non- XML forms. Perhaps you weren't thinking about source when you said that "you can't hide data in XML". Perhaps you meant that the schema component model is public (e.g. exposed through such interfaces as the org.apache.xerces.xs XML Schema API). Even at this level, I'm not really interested in hiding anything, I just want Schema processor- enforced constraints on the *use* of schema components. Does this make any sense, or am I talking rubbish? Mark.
Received on Thursday, 14 September 2006 08:18:00 UTC