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

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

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

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

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

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

Exactly. That's why I don't want to deprecate them! My proposal is to introduce a new element which makes explicit when non-TEI elements have been used, just as we do elsewhere (e.g. with musicNotation!) On 10/11/16 16:14, Raffaele Viglianti 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 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

...

...

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

Maybe you could also say whether you like my proposed solution to the the 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

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

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

On 10/11/16 23:29, Syd Bauman wrote:

* First thought on solving the problem Hugh posted is to just drop support for DTDs and XSDs. :-)

Not really an option

* I'm yet to be convinced that <rngContent> is a good idea, let alone a requirement to move forward, but have not thought about it very much yet -- am willing to be convinced.

Here are my reasons for thinking we should do it. There are plenty of existing ODDs around which use RELAXNG to express content models. We'd like them to move over to using pure ODD, but we can't expect them to do so overnight. Their maintainers/users won't however ever start thinking about it until something changes to bring that possibility to their attention. Hence the suggestion of (effectively) transforming <content> to mean <pure-TEI-content-only>, and providing <rngContent> as a simple transition mechanism. We can discuss later whether we want to move to a deprecation of <rngContent> in a year or two (or an addition of <xsdContent>) when we see how things playout. In the meantime we are (a) making things technically a lot simpler (b) making things a lot more transparent.

* Why would we want to drop support for RNG in content models? Lou wasn't suggesting that initially, and my instinct is that's a bad idea. (Adding XSD is not an idea I'm fond of, but it's better than dropping RNG.)

I wasn't suggesting dropping support for RNG in content models. I am proposing making it explicit rather than letting it sneak in by the back door.

* Remember, the solution to the dreaded dreaded double-declaration- of-id problem is to turn DTD compatibility mode OFF. (We don't want the limitations of DTDs imposed on our RELAX NG.)

Still not really an option, in my view.