Re: [lmi] an xml schema for (single|multiple)_cell_document file XML format

[Greg Chicares]

On 2012-03-13 16:13Z, Václav Slavík wrote:
> 
> On 12 Mar 2012, at 20:19, Greg Chicares wrote:
>
[...answers to your questions, all of which you had guessed correctly...]
>
> 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)

Yes. I'll "version" them before committing...

>> 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?

Indeed it will be frozen forever.

> 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).

That's good to know, but I don't think we want to be that liberal.

Sometimes we manually create a '.cns' file containing various cell
versions for system testing. For instance, we might have one census
that contains one cell of every historical version, as a test of
backward compatibility. Such a chimera needn't validate under any
schema--lmi itself would validate it. But modifying one cell and
saving a census in lmi itself causes all cells to be written with
the current version.

> 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.

I agree.

It's possible that the 'census' and 'illustration containers will have
versions of their own that might change someday, e.g.:

element multiple_cell_document {
    attribute version {"1"},     # THIS IS THE "CONTAINER" VERSION
    element case_default {
        external "cell.rnc" [...]

which in theory would give rise to the census-illustration-cell triplet
1-0-6. However, in practice, 'illustration' has never changed, and
'census' has changed only once, and then only because it had originally
been designed in a way that wasn't readily schematizable--so the 'cell'
version really can control everything. I think this leads us to:

element multiple_cell_document { # THIS WOULD BE VERSIONED 'census-v006.rnc'
    attribute version {"1"},     # CONTAINER VERSION ALMOST NEVER CHANGES
    element case_default {
        external "cell-v006.rnc" # THE CELL SCHEMA IS VERSIONED

and I'll "version" all of '*.rnc' accordingly before the initial commit.