Conflict with xenoData when introducing elements in new namespaces in ODD customizations

[ebeshero]

I discovered this problem while working with students to customize the CBML ODD (for Comic Book Markup Language).

The issue appears when:

• we introduce elements in a new namespace (e.g. http://www.cbml.org/ns/1.0)
• we wish to be checking IDs/IDREFs (with this setting turned on in oXygen)

The output Relax NG in XML syntax in these conditions generates this error on xenoData:

<define name="anyElement_xenoData_1">
      <element>
         <anyName>
            <except>
               <nsName ns="http://www.tei-c.org/ns/1.0"/>
               <name ns="http://www.tei-c.org/ns/Examples">egXML</name>
            </except>
         </anyName>
         <zeroOrMore>
            <attribute>
               <anyName/>
            </attribute>
         </zeroOrMore>
         <zeroOrMore>
            <choice>
               <text/>
               <ref name="anyElement_xenoData_1"/>
            </choice>
         </zeroOrMore>
      </element>
   </define>

The Relax NG error is on the line here, and reads, “conflicting ID-types for attribute “id” from namespace “http:// www.w3.org/XML/1998/ namespace” of element “panel” from namespace “http:// www.cbml.org/ns/1.0”. (When I experimented with removing the cbml:panel definition in the ODD, the error would emerge again on this definition of anyElement_xenoData_1, just mentioning a different CBML element.)

To temporarily solve the problem, simply removing <xenoData> from the teiheader module entirely, or modifying <xenoData> in an elementSpec to exclude the CBML namespace worked. So this is my current patch (thanks to @raffazizzi's advice on the TEI Slack):

<elementSpec ident="xenoData" mode="replace">
    <content>
        <anyElement except="http://www.cbml.org/ns/1.0"/>
    </content>
</elementSpec>

However, we think this should not be necessary. Is there a solution to the problem that doesn't compel ODD customizers to modify the <xenoData> element defintion when we introduce elements in custom namespaces? The ANY or anyElement in our content model for <xenoData> seems to be the problem. @raffazizzi suggests in Slack that perhaps <anyElement> can be adjusted by the ODD processor to exclude new namespaces introduced in an ODD customization?

Here is my customization of CBML for reference on this ticket. (It includes the patchwork to revise <xenoData> in an elementSpec at the very end of the file (line 376).

[hcayless]

I'm afraid this is working as expected. This has come up a number of times before, and I tried explaining it a decade ago on the Council list. The issue is that, by allowing anything, <anyElement> implicitly defines an@xml:id which can contain anything (not just IDs). Because CBML already defines an @xml:id that contains an ID that means if it's allowed in xenoData, it has in there two @xml:id definitions. There's a note about the requirement on the <anyElement> definition. This is a pain, I agree, but its not solvable so far...

[lb42]

We needed you at the tei community call today hugh! I am glad your memory works better than mine....

[hcayless]

Sadly I had a conflict today...I had to remind myself how it worked. It's good that this is all written down somewhere.

[bansp]

(HC) I'm afraid this is working as expected.

... which means that Elisa's patch has a chance to attain the status of the official way to handle (a solvable subset of) such conflicts, correct?

[hcayless]

@bansp Correct. That is how you deal with it.

[sydb]

But worth noting this is a way to deal with it when you are unwilling to turn off ID/IDREF checking in oXygen, or use the -i switch on jing to turn off DTD compatibility mode.

[ebeshero]

@sydb I am, indeed, unwilling to turn off ID/IDREF checking in oXygen. Once upon a time, people persuaded me that it was wise to do such a thing, but it leads to Schematron hacks to help with checking distinct identifiers, and ID/IDREF checking is always worth doing. A proper fix for this problem is most welcome.

[ebeshero]

For documentation that this problem has, indeed been around for a long time (as @hcayless mentions), I'm adding a link to @djbpitt 's Bulgarian Repertorium ODD, and specifically to his changelog entry of 2017-10-18 about having to remove the <xenoData> element: "Exclude xenoData, the presence of which raises mysterious attribute type
errors, apparently because of the introduction of a new namespace into the
schema."

I will add that while David himself in 2025 did not remember this fix, his own past self's documentation led me to try removing <xenoData> on my own to resolve the problem. That underscores the need for us to provide more help to ODD writers on this issue, or perhaps better yet to automate a solution in ODD-processing so we don't have to worry about this. We want to encourage people to introduce custom elements in namespaces and create wonderful ODDs like @jawalsh 's CBML, yes? (The CBML ODD I'm working on here with my students is just an update just to replace the old Relax NG content models and make it easier for my students to customize in @raffazizzi 's Roma.

[peterstadler]

Being late to the party I might be missing something but isn't this why there's @defaultExceptions on <schemaSpec>? It should be enough to add your new namespace there to get rid of the duplicate ID issue.

[peterstadler]

Just tried with @ebeshero's example ODD and changed the schemaSpec at https://github.com/newtfire/textEncoding-Hub/blob/37c1f2695bb814a18efa6a926f7f1d7295c38d98/Class-Examples/CBML/CBML-ODD/cbml.odd#L45 to

<schemaSpec ident="cbml" defaultExceptions="http://www.tei-c.org/ns/1.0 http://www.cbml.org/ns/1.0">

with success.

[raffazizzi]

I completely forgot about that @peterstadler! I figure Roma should manipulate @defaultExceptions when adding/removing elements in a non-default namespace, so I'll open a ticket for that