[
Lists Home |
Date Index |
Thread Index
]
You touch on two points of interest:
1. That schemas can and should be treated as emergent controls, and
that within them, local emergence can be observed (some parts of them
perturbate in fascinating ways and finding the coupler is a great
exercise for enterprise modelers).
2. That schemas can be used to tighten down a pipeline opportunistically
and in some cases, tighter than the other tools being used. In fact,
that
has been a major use where I've used them or seen them used.
What some know from hard experience is that local rules prevail and that
a schema is fine way to localize. They are, as Tim notes, not particularly
good for business rule processing; on the other hand, as people are likely
beginning to notice, a lot of the business rules that were tied into
the GUI logic (eg, onFocus: check that; if not that, display error dialog)
are difficult on the web in general given granularity, statelessness,
and loose coupling. It would be illuminating to see a real world case
of enterprise class applications running on the web to discover how one
does that and still gets a performance the user accepts at that degree
of linearization.
len
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Most of the documents I create this way aren't widely shared, and I
think the assumption that most XML documents actually are made to be
shared in any formal sense is probably mistaken. Still, they do
sometimes grow into something other people find interesting or useful.
>1. It forces you to write down your design formally and exposes
> glaring gaps in your thinking. It does for me, anyhow.
Yes - this is true whether or not something's shared. If it's done
after a few rounds of emergent markup, it's also interesting to examine
and consider the patterns that emerge.
I'd really like to see something like Trang's schema inferencer that
works across multiple documents. Maybe that's too evil a request, and
Examplotron is a good middle ground I should use more often.
>2. It's useful documentation, there are those who really find schemas
> easier to read than instances. Weird but true.
There are a few people like that, yes. I find schemas useful primarily
because they're concise.
>3. It gives you some basic quick-and-dirty validation. Schema-only
> validation is almost never useful at a business level.
I use schema validation regularly for material going to O'Reilly's
production department. I suspect that spares them some minor
inconveniences, but it's still remarkable how many cases are permitted
by the schema but not by tools - and vice-versa. I don't think O'Reilly
is at all unique in this, of course, and I'm generally pleasantly
surprised by how smoothly things go.
>An example that illustrates both 2 and 3 in the list above is the work
>on Atom; clearly something like this needs schemas for reasons 1 and 2,
>but the excellent feed validator does not use a schema-based approach.
I suspect schema-based validation should be treated as an anti-pattern
in a lot of cases, something worth doing at particular points in the
development and creation cycle but dangerous if used as a general (and
particularly as an exclusive) mechanism for inspecting information.
Schematron seems like an interesting mechanism for addressing those
kinds of problems, and maybe patches things enough to make the general
notion useful. I'd have to spend more time with it to decide.
|
