[
Lists Home |
Date Index |
Thread Index
]
Matthew Gertner scripsit:
> No, I meant type derivation. Sorry, should have been more explicit about
> this. I'd be very interested in your view.
Well, I think XSD-style type derivation is just a fairly trivial usage
pattern, with the exception of deriving complex types by restriction,
which is not straightforward in RNG.
Extending complex types is just grouping. If we have a rule
foo = bar, baz, zam
bar = element bar {...}
baz = element baz {...}
zam = element zam {...}
then we can create foo1 thus:
foo1 = foo, quux
quux = element quux {...}
Similarly, you can extend simple types like this:
optint = xsd:int | "N/A"
and restrict them so:
bignum = xsd:long - xsd:int
and of course lists are built in:
tokens = list {token}
If you exercise some care, you can create easy-to-redefine content
models:
foo = element foo {this, that, gap}
this = element this {...}
that = element that {...}
gap = empty
and then include them thus:
include "foo.rng" {gap = tother}
tother = element tother {...}
> RNG (John, you're strengthening my case by abbreviating the
> name!)
Well, it saves typing. "XSD" isn't an official name either.
The *ix family of operating systems have done fairly well for themselves,
at least in the server space, on technical merit, without killer apps.
When there are multiple competing platforms, it's almost always possible
to do what you want on any of them *somehow*, if you are willing to kludge
heavily enough, and of course people do.
> I think this killer app might be related to type derivation. There are a lot
> of problems with XSD derivation that are coming to light as real-world cases
> like UBL are addressed.
Give me a problem and I'll worry it a bit.
--
John Cowan <jcowan@reutershealth.com> http://www.reutershealth.com
I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
|
