lmi
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]