[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: Excessive layering in XML Schemas
- From: cbullard@hiwaay.net
- To: xml-dev@lists.xml.org
- Date: Thu, 13 Aug 2015 10:51:36 -0500
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.
len
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]