Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ODD processing and custom attributes (of existing names) #237
The stylesheets (ODD to RNG) seem in some cases to produce output that is invalid. This happens when trying to create attributes in a custom namespace, that already exist with the same local-name
I get the following two types of errors:
Is this an intentional limitation? Shouldn't non-TEI namespaces have full autonomy?
Or am I approaching this the wrong way?
<classSpec ident="att.global" type="atts" mode="change" module="tei"> <attList> <attDef ident="n" ns="http://www.cceh.uni-koeln.de/hal/ns/1.0"> <desc>The 'hal:n' attribute stores legacy information to keep track of the origin of the text value of its parent element.</desc> <datatype> <rng:text/> </datatype> </attDef> </attList> </classSpec>
which led to the errors mentioned above, but also with
Some hints on how to set up such attributes (of the same name but in a custom namespace) in an ODD specification would be appreciated. I couldn't find much information on this (other than the inclusion of externally defined namespaces such as svg).
One minor point: regular TEI attributes are not in the TEI namespace, they're in the empty namespace. By definition, all unprefixed attributes are in the empty namespace; they don't inherit the namespace of their parent element. That's an XML thing, not a TEI thing.
I can confirm that I can replicate this bug/feature of the stylesheets. If you add a non-TEI element with the same name as an existing TEI element, you can use the attribute @Prefix on <elementSpec> to ensure that the pattern generated from the name in the RelaxNG remains unique. But there is no analogous facility for attributes, partly because TEI attributes don't belong to any namespace (as Martin points out), partly because nobody thought of providing it. You could of course just call your new attribute "notN" or something to show that it's different.
Just to say that I can confirm this as well. I added some new attributes to the TEI element using the tei_math.odd exemplar as a starting point (since I wanted something that worked using another namespace already. ;-) ) Adding a new attribute in another namespace of course worked fine. Adding a new attribute in another namespace that has the same local-name as an existing TEI element did not work.
The ODD I used is: https://gist.github.com/jamescummings/155429676474d9416b8251c717776657
And the define element in the RNG it produced was:
Where you can see there are two optional/attribute elements for n attribute in the mathml namespace. For some reason our processing is doing its job twice here.
However, I note that if I delete this additional optional element for the mathml:n attribute, it doesn't suddenly let me use the TEI global n attribute here. So two things are wrong I think.
Perhaps the problem pointed out by @lb42 is related to
For my actual use case I'll use