[
Lists Home |
Date Index |
Thread Index
]
From: "Don Park" <donpark@docuverse.com>
> Having a schema representation of the parts the RSS reader is interested in
> will be pretty useful. Unfortunately, I don't think current schema
> languages support this use-case well.
I think Schematron may. It allows you to bundle constraints into phases, that
are useful at various stages during processing the document.
For example, one phase might reflect the RSS schema's standard constraints.
Another phase might reflect the promises of the system that generated the
data. And a third phase might reflect the expectations of the system that
is receiving the data.
These kinds of overlaid promises/expectations are clumsy to represent with
conventional schema languages, in particular because they don't have mechanisms
to name them, nor to maintain variants within a single schema.
In Schematron you do this by adding
<phase name="Standard_RSS">
<active pattern="p1" />
<active pattern="p2" />
...
</phase>
<phase name="Ricks_Promises">
<active pattern="p11" />
<active pattern="p12" />
...
</phase>
<phase name="Dons_Expectations">
<active pattern="p11" />
<active pattern="p21" />
<active pattern="p22" />
...
</phase>
and you select the phase you want to run as an invocation parameter.
There is an interesting generalization of this, which came out at an ISO DSDL
meeting, that perhaps the result of validation should be the detection of the
state of a document (i.e. usable in some kind of state machine) rather than just
a boolean validity (and other outcomes). In other words, validation may not
only mean "The expected data was there and in the right places" but also
"the expected data was there and in the right places according to state X".
This would fit schemas into forms systems more. Not sure what the layering
should be.
Cheers
Rick Jelliffe
|
