Menu
▾
▴
#292 GLs say add 'ns' decl, but roma objects
In 22.4.4.2 “Additional constraints” [#TDTAGCONS] we are told “we need to declare the TEI namespace in Schematron”, and the example demonstrates how:
<sch:ns prefix="tei" uri="http://www.tei-c.org/ns/1.0"/>
But actually putting this declaration (or one for the RELAX NG namespace) results in an invalid ISO Schematron file as these two declarations are automagically inserted by `roma` (and by Roma).
But while we're at it, isn't it a bit weird to require a <constraint> and <constraintSpec> ancestry for a namespace declaration? Maybe <sch:ns> should be allowed as a direct child of <schemaSpec>?
a tiny test ODD that demonstrates the problem
curses curses. What way round should it be, do you think? Should the processor do the job, or the ODD author? and (he asks sheepishly), did you see where "roma" does the automagic?
Personally I'm reluctant to have <sch:*> direct children of <schemaSpec>, seems messy, and we invented the constraint stuff to contain all this. I agree its weird, though.
Ah! I *finally* found where the automagic is. P5/Source/Specs/TEI.xml. There are two <constraintSpec> elements there, which simply get copied by odd2odd.xsl, and then extracted by extract-isoschematron.xsl.
I think the best bet would be to not only leave those automagic ones there, but add a whole bunch of the obvious cases (xhtml:, svg:, mml:, dbk:, dc:, etc.). Then teach odd2odd to be smart enough to treat a <sch:ns> that is in the customization ODD file as one that *replaces* an existing <sch:ns> iff the value of prefix= is the same. That make sense?
I think you're right, <sch:*> elements should not be direct children of <schemaSpec>, rather <sch:ns> should be allowed as a child of <constraintSpec>. I.e., the content model of <constraintSpec> would be
model.glossLike*, ( sch:ns | isosch:ns | isosch:let | isosch:include ), constraint
or some such. (I haven't really thought about the list of allowable elements very carefully.) Can someone remind me why a <constraintSpec> can only have 1 <constraint>?
Has this been fixed?
no, the issue remains. odd2odd does not signal an error if the same namespace
is declared twice using <ns>
Last edit: James Cummings 2013-11-10
Setting as RED.