I've been working on https://github.com/TEIC/TEI/issues/1373 https://github.com/TEIC/TEI/issues/1373 and have run into another snag. This time with the tests. A bit of background: Some TEI elements need to contain stuff from other XML namespaces that we don't care to validate. Examples are xenoData and egXML. SVG or MathML might be examples of external namespaces you might want to include data from. Because of bad decisions made long ago by very smart people, RelaxNG automatically does DTD-style ID checking. Elements can't have conflicting ID types, e.g. an id attribute that is an xsd:ID and one that isn't. The difficulty comes in with the way these "catch-all" elements are defined, which is special. They implicitly allow non xsd:ID id attributes (because they allow anything). This means that when you use one of these special "any" elements in a RelaxNG schema, you have to exclude the TEI namespaced elements (because any of them can have @xml:id) and the egXML element (which also allows xml:id, and which is in its own namespace). If you include any external schemas that define IDs, they too must be excluded from these special elements. We solve this now by futzing around with the macro.anyXML element and adding those exclusions to it. With the new <anyElement>, which tackles the unknowable XML content problem in a slightly different way, we make the definition of those special elements a bit cleaner and easier, but we also have to cope with juggling exclusions on more elements. Lou’s proposed changes, which he outlines in http://teic.github.io/TCW/anyXMLproposal.html http://teic.github.io/TCW/anyXMLproposal.html, mean that if a schema pulls in SVG, elements like xenoData must add an exclusion of the SVG namespace. When we used macro.anyXML everywhere, we could do this redefinition in one place, but now we can’t. We have to do it on each included element that uses <anyElement>. You can see the difference by comparing https://github.com/TEIC/TEI/blob/dev/P5/Test/testplace-kml.odd#L32-L53 https://github.com/TEIC/TEI/blob/dev/P5/Test/testplace-kml.odd#L32-L53 and https://github.com/TEIC/TEI/blob/hcayless_anyElement/P5/Test/testplace-kml.o... https://github.com/TEIC/TEI/blob/hcayless_anyElement/P5/Test/testplace-kml.o... But the latter only works in my branch because I’ve done some "magic" with the stylesheets, making the ODD to RelaxNG conversion take additional namespace exclusions in macro.anyXML into account. Otherwise I’d have to redefine xenoData, egXML, and any other elements that can include random XML. If that ODD included tagdocs, I’d have to redefine another 3 elements. So that leads to the question: do we want to come up with a simpler syntax for adding excluded namespaces? I could see putting a new attribute on the moduleRef that pulls in the KML schema, for example…any opinions? I’ve got another problem that may be a bug in trang. There’s a workaround, fortunately. I’ve gone on long enough for one email, I think. :-)
On Mon, Nov 7, 2016 at 4:45 PM, Hugh Cayless
So that leads to the question: do we want to come up with a simpler syntax for adding excluded namespaces? I could see putting a new attribute on the moduleRef that pulls in the KML schema, for example…any opinions?
Is there any chance that this can be done automatically on moduleRefs that point to an external schema with @url? Or would it be too much magic and it would be best to allow encoders to list namespaces instead? I also wonder what are the consequences of this on ODD-defined elements in a different namespace, such as user TEI extensions or when combining two different ODD-defined schemata (e.g. TEI + MEI). In this case, perhaps, the Stylesheets should be able to deal with the exclusion themselves, since they can get distinct values of all @ns attributes. Then, when dealing with an elementSpec with content of anyElement, all the collected namespaces can be excluded. Or maybe it's not as simple as this. Raff
I’ve got another problem that may be a bug in trang. There’s a workaround, fortunately. I’ve gone on long enough for one email, I think. :-) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Maybe...we'd have to inspect the ODD or RNG Schema on the other end of the link, and maybe resolve any includes *that* might have. Not impossible, but perhaps hard. I think the choices are: 1) Try to figure out what namespaces get used in the current and any referenced ODDs or schemas 2) Invent a standard way of defining namespaces to be excluded 3) Use the definition of macro.anyXML as #2 #3 is done, but only because it was convenient, and it means making macro.anyXML special, i.e. unlike other macros, it doesn't get stripped out if not used, and will end up in any derived schema, whether used or not. On Mon, Nov 7, 2016 at 5:02 PM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
On Mon, Nov 7, 2016 at 4:45 PM, Hugh Cayless
wrote: So that leads to the question: do we want to come up with a simpler syntax for adding excluded namespaces? I could see putting a new attribute on the moduleRef that pulls in the KML schema, for example…any opinions?
Is there any chance that this can be done automatically on moduleRefs that point to an external schema with @url? Or would it be too much magic and it would be best to allow encoders to list namespaces instead?
I also wonder what are the consequences of this on ODD-defined elements in a different namespace, such as user TEI extensions or when combining two different ODD-defined schemata (e.g. TEI + MEI). In this case, perhaps, the Stylesheets should be able to deal with the exclusion themselves, since they can get distinct values of all @ns attributes. Then, when dealing with an elementSpec with content of anyElement, all the collected namespaces can be excluded. Or maybe it's not as simple as this.
Raff
I’ve got another problem that may be a bug in trang. There’s a workaround, fortunately. I’ve gone on long enough for one email, I think. :-) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
After the ODD is compiled all the namespaces should be available there.
Maybe this can be solved with a post-compilation step. Though maybe not for
RNG schemas.
On Tue, Nov 8, 2016 at 11:44 AM, Hugh Cayless
Maybe...we'd have to inspect the ODD or RNG Schema on the other end of the link, and maybe resolve any includes *that* might have. Not impossible, but perhaps hard. I think the choices are:
1) Try to figure out what namespaces get used in the current and any referenced ODDs or schemas 2) Invent a standard way of defining namespaces to be excluded 3) Use the definition of macro.anyXML as #2
#3 is done, but only because it was convenient, and it means making macro.anyXML special, i.e. unlike other macros, it doesn't get stripped out if not used, and will end up in any derived schema, whether used or not.
On Mon, Nov 7, 2016 at 5:02 PM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
On Mon, Nov 7, 2016 at 4:45 PM, Hugh Cayless
wrote: So that leads to the question: do we want to come up with a simpler syntax for adding excluded namespaces? I could see putting a new attribute on the moduleRef that pulls in the KML schema, for example…any opinions?
Is there any chance that this can be done automatically on moduleRefs that point to an external schema with @url? Or would it be too much magic and it would be best to allow encoders to list namespaces instead?
I also wonder what are the consequences of this on ODD-defined elements in a different namespace, such as user TEI extensions or when combining two different ODD-defined schemata (e.g. TEI + MEI). In this case, perhaps, the Stylesheets should be able to deal with the exclusion themselves, since they can get distinct values of all @ns attributes. Then, when dealing with an elementSpec with content of anyElement, all the collected namespaces can be excluded. Or maybe it's not as simple as this.
Raff
I’ve got another problem that may be a bug in trang. There’s a workaround, fortunately. I’ve gone on long enough for one email, I think. :-) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
participants (2)
-
Hugh Cayless
-
Raffaele Viglianti