Re: [tei-council] anyElement XSD pain

You mean for the datatypes? I think mostly it boils down to numerical ranges. I did say at the last F2F that I would come up with a proposal. Apologies for the delay there. https://github.com/TEIC/TEI/issues/1473 And the problem is not just MEI's https://github.com/TEIC/TEI/issues/1344 I have no real issue with introducing something like rngContent, expect that it would be so much better to just be in the position to wave RNG away. Raff On Thu, Nov 10, 2016 at 11:30 AM, Hugh Cayless wrote:

What would we need to do to add that support? I remember you bringing this up earlier, but I'm foggy on the details...

On Thu, Nov 10, 2016 at 11:14 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

...

Deprecating RNG models would break MEI. Just FYI. PureODD is not ready for datatypes that cannot be constrained with regular expressions.

On Thu, Nov 10, 2016 at 11:10 AM, Hugh Cayless wrote:

...

To me, it means getting rid of the last absolute requirement for an RNG content model, which was in macro.anyXML, so we're almost there. By "it", I mean deprecate RNG content models.

On Thu, Nov 10, 2016 at 11:07 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

...

What does "fully in place" mean, if it doesn't mean introducing rngContent?

Why is it obvious that we can't do it yet? (assuming "it" means "introduce rngContent" ?

On 10/11/16 15:59, Hugh Cayless wrote:

...

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 < lou.burnard@retired.ox.ac.uk> wrote:

...

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

...

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

...

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

...

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

...

>>> problem. >>> >>> Relax allows you to say "these elements/namespaces can't occur in

...

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

Maybe you could also say whether you like my proposed solution to the problem.So point they'd the the 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

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

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