[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] an xml schema for (single|multiple)_cell_document file XML for
From: |
Václav Slavík |
Subject: |
Re: [lmi] an xml schema for (single|multiple)_cell_document file XML format |
Date: |
Tue, 13 Mar 2012 17:13:51 +0100 |
Hi,
On 12 Mar 2012, at 20:19, Greg Chicares wrote:
> The schema should treat every element under <cell> as required,
...
> I don't see a good reason not to specify that elements must be sorted
> in the exact order given in the schema.
...
> I'd rather say that each of
> case_default
> class_defaults
> particular_cells
> must contain at least one <cell>.
Then I think the schemas from
https://savannah.nongnu.org/support/index.php?107981 are finished (now that I
updated census.rnc to remove size_hint), they behave like this.
> But we will want a schema for version seven when it comes into being.
> Not knowing much about schema languages, I was thinking it'd be okay
> to have a separate schema for each of versions 6, 7, and so on. An
> external system might still use version seven when lmi moves to version
> eight--for instance, because the new version adds a field that wouldn't
> mean anything to that external system (and those systems are costly to
> update). Perhaps you'd design it with multiple files:
> schema-v6.rng
> schema-v7.rng [future]
> generally-useful-stuff.rng [potentially shared by -v6 and -v7]
> but would it be so horrible to duplicate a file:
> generally-useful-stuff-v6.rng
> generally-useful-stuff-v7.rng
> whose contents, after all, might change?
It would be somewhat tricky to organize the files so that the content can be
shared like this — cell.rnc, where most changes will happen, has flat
structure. I think it's OK to have cell-v6.rnc etc. — after all, the old schema
will become frozen when the version is increased, won't it?
RELAX NG can handle alternatives and multiple versions can be supported
naturally:
element single_cell_document {
external "cell_v6.rnc" | external "cell_v7.rnc"
}
Or to show it in greater detail:
element cell {
(
attribute version {"6"},
element AccidentalDeathBenefit {lmibool},
...
) |
(
attribute version {"7"},
element SomethingElse {lmibool},
...
)
}
The validator attempts to match the choices. If it cannot match the v6 choice
on a document that contains <cell version="7">, it will try the other choice
(and require SomethingElse child element and refuse AccidentalDeathBenefit).
In theory, we could accumulate the versions in this way and always have a
"grand schema" that validates any version. Note that it wouldn't be
representable as XML Schema then, though, it cannot handle choice based on
attribute value. Personally, I think it's not worth doing and it's better to
keep separate foo-vN.rnc files.
Regards,
Vaclav