The anyXML thing is not quite as you describe it. if the macro is declared in the tagdocs module, as it currently is, then you won't get it unless you include that module in your schema. If you want to use it in xenodata, then you need to declare it in the infrastructure module. the @predeclare thing is not really relevant: it is a legacy piece of trickery whjich we should not be using. Just move the declaration to the infrastructure module and add the appropriate text into chapter ST would be my recommendation. On 02/10/15 13:35, Syd Bauman wrote:
What? That's crazy. I never touched fvLib.xml, at least not by hand. It seems like the only time that file was altered in branch sydb-xenodata was 09-11 by Martin to change pointers to NVDL schemas (ostensibly in the xml-model PI, which wouldn't touch this), and on 09-29 when I merged changes that had occurred on master into that branch. Is that the merge you refer to, or when Hugh merged sydb-xenodata back into master yesterday?
Either way, I'm really worried that other problems may have been introduced. I have this sinking feeling in my git ...
If I understand correctly, predeclare=true means that the declaration for the structure (in this case, macro.anyXML) gets output not in the schema fragment in which it is declared (in this case 'tagdocs'), but rather in the 'tei' architecture schema fragment. This was needed because the new <xenoData> element, which uses macro.anyXML in its content model, is declared in the 'header' module. Schemas are loaded 'tei' first, and then the rest in alphabetical order. So header.rnc was referring to macro.anyXML which, since tagdocs.rnc had not been loaded yet, was not declared. Moving the declaration of macro.anyXML into the first schema loaded (along with most of the other macros) solves that.
AFAIK, this only affects use of the schemas when one wants to use them as fragments as we used to do when we constructed pizzas.[1] I don't even remember how to do that with RELAX NG, and AFAIK we provide no documentation to tell users how to do that with either RELAX NG or DTDs. And I've never heard of anyone doing it.
Notes ----- [1] Although logically it might affect flattened DTDs, too, I presume we test for that in the build process. Do we?
FWIW, you seem to have reintroduced a nonsensical content model
fvLib (prior to your merge)
<content> <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <ref name="model.featureVal"/> </zeroOrMore> </content>
fvLib (after your merge)
<content> <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <choice> <ref name="model.featureVal"/> </choice> </zeroOrMore> </content>
This doesnt affect schema production, and is thus benign. But, if for some reason we have to rerun the purification of content models script again before I merge in the pure ODD branch, this one will need hand fixing again.
And I don't understand (never have) what @preDeclare is doing.