- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 14 Sep 2006 12:56:12 -0400
- To: "Michael Kay" <mike@saxonica.com>
- Cc: "'Mark Goodhand'" <mrg@decisionsoft.com>, xmlschema-dev@w3.org
What I hear Mark asking for is visibility control of named components, e.g. the ability to restrict visibility to the document in which the declarations or definitions occur. First of all, I can see the use cases for this. That said, the schema languge is rightly criticised for being too complex, having too many little switches and features, being too hard to learn, and taking too much effort to implement. I can't see a way to meet this "requirement" without adding yet more features, yet more implementation complexity, yet more testing complexity etc. Further more, as I once said in a talk, my experiences with the XML Schema language have convinced me that "there's no such thing as a simple feature." Taken in isolation, it's easy to see how access controls would work. Maybe or maybe not they would prove to be a nice little isolated capability, and largely orthogonal to the rest of the language, but I have my doubts. I can't point to any specific "gotchas" offhand, but it wouldn't surprise me to find ourselves in a few months embroiled in some obscure discussion involving refinement, model groups or some such that involved references to "private" components. I'm often reminded of the claim that was made by some members of the Schema workgroup that we needed to do locally scoped elements (another reasonable request) and that surely they'd be simple because local scoping was known technology from other programming languages. I can't think of any feature that's caused more design complexity in practice. To pick one detail, the whole elementForm/elementFormDefault business would never have come up had we done what DTDs did and had only globals (though possibly with convenience syntax that would closely resemble today's ability to declare one element inside the content model for another.) So, I think that visibility controls are a sensible idea in principle, but I would want to see very compelling evidence of the requirement before actually adding new features to the language. I do note that some mileage could be gotten from layered specs. For example, someone could specify a "HideMe" annotation, and could build tooling to ensure that no inter-document references were made to components so marked. A little clumsy, but it nicely separates the concerns, I think. > What this means, I think, is that it's incorrect to assume (as > xs:import does, for example) that you can identify a schema by > its target namespace alone. That's not quite how I'd look at xs:import without a schema location. What it says is: "we're not going to tell you here how to find any components needed to validate the imported namespace." So, the policy for finding the schema is external to the importing schema document. That policy may depend on many factors other than the namespace name. E.g., it could depend on the database column in which the instance to be validated is stored, it could depend on the application doing the validation (which might supply the schema, perhaps in the form of schema documents or perhaps not), and so on. In fact, I've always argued that xs:import without schemalocation is really just an early hint to tooling that there may be constructs in the form ref="ns:local" coming later, where ns binds to the imported namespace. I think you'll find that, other than schemaLocation, the language would work exactly the same way if import were eliminated entirely. It's just that you wouldn't be able to tell what namespaces were used until you'd parsed the entire schema document. Rightly or wrongly (and I've worried about our choice since the day we made it), we decided that the added complexity and possibly confusion surrounding xs:import was offset by the easy ability for tools to easily find out which namespaces were referenced. I don't think the intent was to say that the resolution could depend only on the namespace name. Thanks! -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Thursday, 14 September 2006 16:56:31 UTC