|
Enjoying (and biting my tounge) on this discussion since Balisage. Totally agree with Kurt it’s a trade-off issue and the arguments on both sides are reasonable *in context* … but where I want to bite my tounge Is a black and white statement like “Using schemas are bad” or “Flexibility is always good” This last email from kurt unpinned an old neuron …
For those who haven’t, or haven’t recently I highly recommend this short classic
“In the beginning was the command line” A quick read , for free from the author directly (with permission, no strings ) http://www.cryptonomicon.com/beginning.html 1999 Or if you would rather pay $10 http://www.amazon.com/Beginning-was-Command-Line-Neal-Stephenson/dp/0380815931 I wont spoil it for you but the ending is great. It is a short essay on the comparison of Windows vs Linux evolution, focusing on the business model and the GUI Where Linux is the metaphore for “flexable and free” and windows is the metaphore for “constrained and commercial” I think the comparison to schema vs schema free is quite close … a bit off … but speaks better then I can about the tradeoffs And what happens if you go one way or the other too far. ---------------------------------------- David A. Lee From: Kurt Cagle [mailto:kurt.cagle@gmail.com]
To me, it's an issue of trade-offs. Standardization, which I think is at the root of Simon's comments, is efficient - you in effect create a single set of designs, making it possible to custom manufacture parts or pieces in parallel for
many different projects simultaneously. What you lose with that efficiency is flexibilty - the ability to move outside of the standard, to add embellishments on the design to fit specific needs. This is true of data modeling regardless of whether you're talking
about UML, XSD or (to an extent) OWL. In theory, the RDF open world assumption mitigates this somewhat; you define the behavior of a model for those cases where you need specificity, but unless you specifically disallow it you do not implicitly disallow non-standard relationships
- the analogy of customization or ornamentation. Of course, the downside to this is that the non-standard components do not then have rules specifying their behavior, because they are, by definition, outside of the schematic model being created. In practice,
what this usually means is that your schema makes an assumption that those parts that are not defined within that schema will be defined at some point by some other schema. This corresponds (roughly) to xsd:any with lax validation. Of course, I've seen way too many XSD schemas that were designed in such a way as to not allow for this escape hatch, and indeed, a lot of tools that utilize XSD schemas - such as JAXB for Java object serialization of schemas - go positively
crazy in the presence of xsd:any. That has to do more with the fact that most people do not understand validation or data modeling with a hatch for flexibility than it does with tools. They see validation as binary (something is or is not valid) rather than
contextual (something is this valid in that context). This becomes more evident when you create contextual bindings (such as XSD 1.1 or Schematron), but neither has achieved the degree of awareness that XSD has, principally because XSD 1.0 is so inextricably
bound up with WSDL.
Kurt Cagle Managing Editor, XMLToday.org 443-837-8725 On Wed, Aug 28, 2013 at 10:23 AM, Lauren Wood <lauren@textuality.com> wrote:
The idea is that if the parser can tell what is missing The hard part with these fixes is knowing when to stop. The law of diminishing returns kicks in fairly quickly on error conditions, especially when the schema isn't constrained. For example, it's much easier to correctly correct the missing
end tags when the schema is constrained (e.g., you at least know which elements are meant to be empty, and which not). In my experience if your parser makes the wrong choice and therefore 'corrects' the wrong thing, or corrects it in the wrong way, the resulting
mess can be difficult to fix properly. Of course, depending on your downstream processing, that may or may not matter.
|