OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: Excessive layering in XML Schemas

The few times I've written XSD from scratch, I overlayered when I did not constrain the domain in advance by constraining either the use cases or by doing a bit too much research and trying to capture all that I read in my own distilled abstractions. It is all too easy to wander into the marshes of side
issues or otherwise boil the ocean.

When using schemas from outside sources, it depends on my own role in the
organization. I have a habit from the early years of reading the schema to
answer questions rather than trusting the schema-aware editor. So when someone
comes to my office and asks if they can do something or why something isn't
working my first reaction is to open the schema and sort through the layers to
find the expression that actually determines an occurrence. That gets gnarly
when there are lots of not-terribly-descriptive names and names of names.

It seems to come back to the too-many-incompatible-but-consensual points of view being accomodated in a single schema. I give the S1000D folks cred for breaking those up.

Object-layering usually implies running code. A similar problem but not quite the same in that getting it wrong means rewriting a lot of functions or methods and that is never fun. Here it seems one can stay simple as long as one is the only person writing that code. In teams it gets harder as more classes are added and one has to explore to find the right one for the task at hand,

The real world is messy as Kay says and code is not the real world. On the other hand if the real world has to work too hard to use the code or process the results, it's time to go back to the design and rework it if possible. OTOOH, after a recent stint working in a tagging trench with a group attempting to dig out of a messy conversion (XML to XML), I am more than ever convinced that lack of training and actually resisting code is a bigger problem for those who procure XML services without evaluating the humans who provide them. I still see tagging armies taking months to do jobs that a properly configured and enabled XML system can do in minutes. The costs are prohibitive and our governments pay them because they don't take the time to learn what is possible and what is silly.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS