Lists Home |
Date Index |
- From: Rick JELLIFFE <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 10 Aug 2000 21:24:25 +0800
Francis Norton wrote:
> Have these use cases been published?
No as such. Some, like the ones in the Primer, and the schema for
schemas, and XHTML are all very prominant examples, though.
> For me the key element of
> difficulty reading the part 1 spec is that it appears to be a complex
> solution that has been abstracted out from the a lot of the problems it
> is designed to solve. Technical specs are like novels, understanding
> motivations casts light on everything.
Yes. But the fat lady is still doing her voice warmups!
Two problems which can be pretty clearly traced from feature back to use
case are nullability and uniqueness/key constraints. These are obviously
both database-related features first and foremost. I think the
uniqueness/key mechanism owes a lot to keys in XSLT as far as its
approach: people seem pretty happy with that. (Schematron has limited
key support too, to a different end. RELAX only has IDs AFAIK.)
But the current nullability mechanism (only element contents can be
nulls?) looks a little arbitrarily limited to me: on the other hand, if
we expanded into a full-blown exception-handling mechanism (so that the
WF data could have exceptions and errors built in, and the receiving
system could handle the data properly would help robustify distributed
processing, but it would make the language more complicated and further
away from people's expectations. (Schematron and RELAX have no nulls
AFAIK.) It would be nice to see some discussion about whether a schema
language for integration with SQL and Query languages needs nulls, and
how to do it.