- From: David Carver <kingargyle@gmail.com>
- Date: Fri, 23 Mar 2007 16:01:36 -0500
- To: Bryan Rasmussen <BRS@itst.dk>
- CC: Michael Kay <mike@saxonica.com>, xmlschema-dev@w3.org, "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Bryan Rasmussen wrote: > Thus what one ends up with is XML like this > > <a:ProblemDomainDocumentElement xmlns:a="http://example.org/a" > xmlns:b="http://example.org/b"> > <b:ProblemDomainClass>something or other here</b:ProblemDomainClass> > </a:ProblemDomainDocumentElement> > > now I have seen a lot of this kind of structure over the last few years and I > really can't remember seeing much of it before XML Schema became the de facto > standard for doing validation in XML. And I think it is a response to this > lack of being able to define a validation root. But you may have another > opinion. > In some ways yes, the root validation is cause for this type of design. Personally, I like the global element concept not just for the use of multiple schemas that can reuse various modules, but because used correctly and dilligently it makes defining semantics much easier and resuable across various schemas. The issue you bring up is compounded by the over zealous use of namespaces, where people try to come up with the perfect design. There comes a point where real word, and theory just don't mix. An example, in some NDR specs for representing a model in schema, it has been stated that every code list must have it's own namespace. This in itself could lead to an application or a schema having to support litterally hundreds of namespaces. When in practical reality, code lists are typically stored in one common namespace and reused. It's the difference between what looks like a perfect design, and what is good enough to work to get the job done. Namespaces themselves aren't bad, it's how they get implemented that is bad. Dave
Received on Friday, 23 March 2007 20:00:30 UTC