Just to follow up: I would really appreciate some discussion of this. I did stuff to make it work, but it's a little hacky. Intuitively, it seems to me that @include and @except should be mutually exclusive—if you have one there's no need for the other. Practically, given RelaxNG as a pivot format, I decided to use both together, because it makes explicit what's being excluded, and therefore clear to people extending TEI how to exclude additional namespaces. Maybe it's better to do some "magic" if it's more logical in the ODD though? On Fri, Nov 11, 2016 at 9:29 AM, Hugh Cayless wrote:

Thanks Lou. I don't feel very strongly about my implementation decisions—I just had to make some to get the thing working, and as you note, they all have implications. More comments below:

On Fri, Nov 11, 2016 at 3:23 AM, Lou Burnard

...

wrote:

...

While yielding to no-one in my admiration for Hugh's efforts, which mean we now have a functioning implementation of it, I still have some concerns about the way the <anyElement> construct is currently implemented.

The current content model for <content> is:

<alternate> <anyElement include="http://relaxng.org/ns/structure/1.0" except=" http://www.tei-c.org/ns/1.0 teix:egXML"/> <classRef minOccurs="0" maxOccurs="unbounded" key="model.contentPart" />

Firstly: <anyElement> is a member of the class model.contentPart, so why is it mentioned as an alternate? The answer presumably is because we want to allow a content model to contain either an element from the RNG namespace or lots of members of the pure ODD class which includes anyElement.

anyElement is sort of a macro. Each instance of it gets compiled into a unique definition in the schema. It must be thus, because different anyElements can have different "signatures" (i.e. different patterns of inclusion and exclusion) and because the RelaxNG implementation of ANY is self-referencing—so it has to have a thing to refer to.

Because it's sort of a macro, the anyElement element itself is different from its expansion. Permitting anyElement in an element's content is different from actually using it. The content element can contain anyElement, but it can also contain RelaxNG elements—the expansion of the anyElement in content's definition. Again, an instance of anyElement is different from the idea of one.

...

Secondly: despite appearances, in particular, despite its name, this anyElement declaration generates RNG which matches *several* elements from the RNG namespace. To be precise it generates a pattern "TEI_anyRelax+" which is not explicitly specified anywhere in the ODD language, but (presumably) created by some cunning hocus pocus when the anyElement is processed. This make me feel uneasy: why didnt we just define a macro called anyRelax in the ODD?

I dunno. Why didn't we? anyElement is basically a shorthand for doing this kind of thing, no? It's specified in content's content model, by the anyElement there.

...

Thirdly: as an ODD user I am bewildered by how to interpret a combination of @include and @except attributes. Elsewhere these attributes are understood to be mutually exclusive; the @include is an exclusive inclusion. So you might suppose that an element which permits only elements from the RNG namespace cannot ipso facto also include elements from any other namespace. But in fact this is not the case: here @include means "there must be elements from this namespace", and @exclude means "there may not be elements from this namespace". The doc needs to make that a lot clearer : since it is not what these attributes mean on e.g. <moduleRef>. I also find confusing the presence of "teix:egXML" as a component of what is billed as being a list of namespaces, since whatever else it is, it aint a namespace. Howe

Yeah, I was of two minds about this, as you could probably see from the comments on the GitHub Issues. As we know all too painfully well, namespace/elements with @xml:id or other attributes of xsd:ID type can't be permitted in anyElement's expansion (pace Syd). The usual suspects in TEI files are the TEI namespace and egXML. Remember, RelaxNG and XSD are basically opposite in how they handle anyElement content. RelaxNG is purely negative, you can only exclude, and as I noted above, we *have* to exclude. XSD is, with one exception, purely affirmative. You can only say what namespaces are allowed, though you can say "any namespace other than that of the current parent". Back again to RelaxNG though, which is the problem child here: we must exclude certain namespaces/elements, but we also want to be able to constrain them (which is what @include does). @include is implemented in RelaxNG with Schematron.

The short version is that exclusion and inclusion are separate concerns in RelaxNG. That doesn't mean they have to be in Pure ODD, but given that exclusion is mandatory, I chose not to obtain the list of exclusions by magic. We should absolutely debate this! If the exclusion list is to be populated by "magic" there's also the question of where it comes from and should we explicitly document it somewhere in the ODD. I'm by no means wedded to the solution I came up with.

...

Both the latter concerns can be addressed by a simple renaming: I suggest renaming @include as @require and @except as @exclude

I am less sure what to do about the other two.

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