I guess my main question is whether we shouldn't be thinking instead about
a deprecation schedule for RNG content models once Pure ODD is fully in
place. Obviously we can't do it yet, but do you think it's something people
will need long term?
On Thu, Nov 10, 2016 at 10:49 AM, Lou Burnard
Maybe you could also say whether you like my proposed solution to the ambiguity problem? or have you found a better way of avoiding it?
On 10/11/16 15:11, Hugh Cayless wrote:
I've been working on this stuff in branches on TEI and the Stylesheets. Think I've got it working, and will merge back to dev shortly. That might be a better basis for this. Also, since we're getting close to "freezing", we'll need to decide soon what to ship and what to save for later...
On Thu, Nov 10, 2016 at 9:53 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:
I spent some time this morning trying to implement my suggested solution
"2a" below. My first definition for rngContent looked like this:
<content> <anyElement include="http://relaxng.org/ns/structure/1.0" maxOccurs="unbounded" minOccurs="0"/> </content>
Predictably, this hit the dreaded double-declaration-of-id problem.So (with some misgivings) I changed it too
<content> <anyElement include="http://relaxng.org/ns/structure/1.0" except="http://www.tei-c.org/ns/Examples http://www.tei-c.org/ns/1.0" maxOccurs="unbounded" minOccurs="0"/> </content>
which appears to have worked, at least up to the point where the standard tests start trying fancy stuff like including mathML. At which point (as noted by Hugh) this method falls over.
On 10/11/16 06:29, Lou Burnard wrote:
This problem arises because of a desire to retain the ability to express
content models in RNG alongside their expression in Pure ODD. This is a reasonable goal, but (as I already noticed) infeasible. It also seems a bit strange to imagine a real world situation where someone would define a content model in RNG in order to get output in XSD: surely they'd rather express the content model in XSD?
I have a better solution, I think. Certainly a cleaner and simpler one.
1. We define a new element called rngContent which has a content model permitting only elements in the RELAX namespace.
2.a EITHER Wherever we currently say "content" in a content model (not many places), if we want to permit content expressed in RNG, we change it to "content|rngContent"
2.b OR We also define a class called model.contentModel and add both "content" and "rngContent" to it. Then change "content" to "classRef key="model.contentModel"
If you go for 2.b this would allow us in the future to permit xsdContent to cater for the person who really just wants to use XSD to define their extensions.
Yes, it's going to break a lot of existing ODDs. But (as Kevin just noticed) the datatype changes in pure ODD already did that.
And may I remind Council that we've been saying we want to move to pure ODD for many years now. This is just the last bit of umbilical cord cutting ...
-------- Original Message -------- Subject: [tei-council] anyElement XSD pain From: Hugh Cayless To: TEI Council CC:
Because of the way we use RelaxNG as a pivot format in generating XSD, we're going to end up with invalid XSDs around the anyElement issue. Basically, XSD handles "anyXML" sections differently than RelaxNG, and so Relax discards information we can provide with anyElement to avoid the problem.
Relax allows you to say "these elements/namespaces can't occur in the spot where any XML is allowed."
XSD, on the other hand, lets you say any XML but "only these namespaces here", and/or "any namespace but the default one".
Pure ODD is basically capable of saying either of these things, but as far as XSD, because we pipe through Relax, it ends up being able to say neither of them. This is a problem, because in the case of things like , which can contain either Pure ODD TEI elements or RelaxNG, an means you have a nondeterministic content model (because "any" includes TEI elements). The XSD solution would be to say , but we can't get there from here.
The long term solution is probably direct generation of XSD, which is something we'd like for other reasons. Near term might be to scale back use of anyElement or add a post-processing step to XSD generation that puts the necessary information back.
Ideas? -- 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