search

TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
273 stars 88 forks source link

GLs say add 'ns' decl, but roma objects #941

Open TEITechnicalCouncil opened 13 years ago

TEITechnicalCouncil commented 13 years ago

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"/&gt; 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>?

Original comment by: @sydb

TEITechnicalCouncil commented 8 years ago

This issue was originally assigned to SF user: rahtz Current user is: sebastianrahtz

TEITechnicalCouncil commented 13 years ago

a tiny test ODD that demonstrates the problem

Original comment by: @sydb

TEITechnicalCouncil commented 13 years ago

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.

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 13 years ago

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

Original comment by: @sydb

TEITechnicalCouncil commented 10 years ago

Has this been fixed?

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

no, the issue remains. odd2odd does not signal an error if the same namespace is declared twice using <ns>

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 10 years ago

Original comment by: @jamescummings

TEITechnicalCouncil commented 10 years ago

Setting as RED.

Original comment by: @jamescummings

peterstadler commented 8 years ago

I wonder if this is a Roma or rather a Stylesheets issue?