The laws about chaining ODDs are indeed arcane and mysterious. That's partly why I didn't say anything about the topic in my document, but clearly I should. Once I've understood it myself that is... On 06/10/16 16:37, Hugh Cayless wrote:

I was playing around last night with chaining ODDs and thinking we needed better documentation for them, so this is a nice start. One thing that tripped me up last night is that it isn't clear that @source has to point at a *compiled* ODD, so you can't just point at the latest EpiDoc ODD, for example, you have to run it through teitoodd first. I can see why that's so, but wonder if there's any way around it...

On Thu, Oct 6, 2016 at 11:28 AM, Lou Burnard wrote:

...

On my way home from Vienna I started drafting a little homily about how to update your old ODD to a pure new shiny one. The source is in github under TEI/Documentation/pureODD/purifyDoc.xml

CETEICEAN renders it reasonably well (modulo a couple of gotchas on which I've posted issues) at http://teic.github.io/TCW/purifyDoc.html, but the nicest reading version is at http://teic.github.io/TCW/puri fyDoc_static.html

I'd very much welcome Council's comments before exposing it further. Seems to me we need to promote ODD a bit more, and this might be a good start. I'm also working on an "ODD for beginners" guide, but this one is aimed at old lags who made an ODD back in the day and are interested in getting up to speed with its new possibilities. So much so (I now realise) that I've completely forgotten to mention the existence of Roma in it. But I'll stop tweaking for now anent your comments...

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

My guess would be this is because tei_bare doesn't include tagdocs. So you're referencing a module that doesn't exist, as far as it's concerned? If this is how it works, then you can only ever subset chained ODDs, not restore already-filtered stuff, which means it would actually be unusable for my own current purpose—basing a critical editions ODD on EpiDoc, because we want to put back some stuff EpiDoc removes. That's kind of a bummer. Maybe we need to think about how we'd want chaining to work, and then figure out how to make that happen instead? On Fri, Oct 7, 2016 at 11:28 AM, Lou Burnard wrote:

I am having trouble getting odd chaining to work at all.

Can anyone explain to me why the following doesn't do what I expect?

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="tagdocs"/> </schemaSpec>

(The file tei_bare.subset.xml is one I produced by running the published ODD for tei_bare through teitoodd)

In my mind, this ought to give me a schema which contains the same as tei_bare plus the elements defined in the tagdocs module. In fact it gives me a schema with no elements at all.

I must be missing something obvious. Maybe someone could send me an example of an ODD chaining which does work?

On 06/10/16 16:37, Hugh Cayless wrote:

...

I was playing around last night with chaining ODDs and thinking we needed better documentation for them, so this is a nice start. One thing that tripped me up last night is that it isn't clear that @source has to point at a *compiled* ODD, so you can't just point at the latest EpiDoc ODD, for example, you have to run it through teitoodd first. I can see why that's so, but wonder if there's any way around it...

On Thu, Oct 6, 2016 at 11:28 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

On my way home from Vienna I started drafting a little homily about how to

...

update your old ODD to a pure new shiny one. The source is in github under TEI/Documentation/pureODD/purifyDoc.xml

CETEICEAN renders it reasonably well (modulo a couple of gotchas on which I've posted issues) at http://teic.github.io/TCW/purifyDoc.html, but the nicest reading version is at http://teic.github.io/TCW/puri fyDoc_static.html

I'd very much welcome Council's comments before exposing it further. Seems to me we need to promote ODD a bit more, and this might be a good start. I'm also working on an "ODD for beginners" guide, but this one is aimed at old lags who made an ODD back in the day and are interested in getting up to speed with its new possibilities. So much so (I now realise) that I've completely forgotten to mention the existence of Roma in it. But I'll stop tweaking for now anent your comments...

-- 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 expect that would work, yeah. I think what you really want though is to be able to pull a moduleRef off a different @source. What if we let you use @source on moduleRef as well? On Fri, Oct 7, 2016 at 12:29 PM, Lou Burnard wrote:

Yes, that does seem to be the problem (James is saying the same thing in another window).

It doesn't seem unreasonable to want to start from an existing ODD and then add some more declarations or modules to it. An ODD processor has to be able to reconcile multiple spec elements anyway. I wonder if it would work if I just copied the specs from the tagdocs module into my new ODD?

On 07/10/16 17:22, Hugh Cayless wrote:

...

My guess would be this is because tei_bare doesn't include tagdocs. So you're referencing a module that doesn't exist, as far as it's concerned?

If this is how it works, then you can only ever subset chained ODDs, not restore already-filtered stuff, which means it would actually be unusable for my own current purpose—basing a critical editions ODD on EpiDoc, because we want to put back some stuff EpiDoc removes. That's kind of a bummer. Maybe we need to think about how we'd want chaining to work, and then figure out how to make that happen instead?

On Fri, Oct 7, 2016 at 11:28 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

I am having trouble getting odd chaining to work at all.

...

Can anyone explain to me why the following doesn't do what I expect?

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="tagdocs"/> </schemaSpec>

(The file tei_bare.subset.xml is one I produced by running the published ODD for tei_bare through teitoodd)

In my mind, this ought to give me a schema which contains the same as tei_bare plus the elements defined in the tagdocs module. In fact it gives me a schema with no elements at all.

I must be missing something obvious. Maybe someone could send me an example of an ODD chaining which does work?

On 06/10/16 16:37, Hugh Cayless wrote:

I was playing around last night with chaining ODDs and thinking we needed

...

better documentation for them, so this is a nice start. One thing that tripped me up last night is that it isn't clear that @source has to point at a *compiled* ODD, so you can't just point at the latest EpiDoc ODD, for example, you have to run it through teitoodd first. I can see why that's so, but wonder if there's any way around it...

On Thu, Oct 6, 2016 at 11:28 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

On my way home from Vienna I started drafting a little homily about how to

...

update your old ODD to a pure new shiny one. The source is in github under TEI/Documentation/pureODD/purifyDoc.xml

CETEICEAN renders it reasonably well (modulo a couple of gotchas on which I've posted issues) at http://teic.github.io/TCW/purifyDoc.html, but the nicest reading version is at http://teic.github.io/TCW/puri fyDoc_static.html

I'd very much welcome Council's comments before exposing it further. Seems to me we need to promote ODD a bit more, and this might be a good start. I'm also working on an "ODD for beginners" guide, but this one is aimed at old lags who made an ODD back in the day and are interested in getting up to speed with its new possibilities. So much so (I now realise) that I've completely forgotten to mention the existence of Roma in it. But I'll stop tweaking for now anent your comments...

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

Sorry to have waited so long to pick this back up. I was off at a conference last week, so I didn't have the bandwidth to investigate further. Lou, is that your whole ODD? If so, I think the problem may be that you still need to put moduleRefs in the derived ODD. You don't seem to get them for free from the source. I'm finding that this all works, pretty much, but there are some interesting gotchas. Here's my scenario: I want to make a critical editions ODD that's based on EpiDoc, but that puts back a few things EpiDoc leaves out, like tables, for example. As Lou mentioned, I can point to the EpiDoc compiled ODD on my schemaSpec, but then at the p5subset.xml on my moduleRefs, effectively bypassing the parts where EpiDoc has stripped out something useful, so my schemaSpec looks like: <schemaSpec ident="tei-DLL" docLang="en" prefix="tei_" start="TEI" xml:lang= "en" source="tei-epidoc-full.odd"> ... The EpiDoc modueRef for figures looks like: <moduleRef key="figures" except="cell formula row table"/> but mine looks like: <moduleRef key="figures" except="formula" source= "../../TEIC/TEI/P5/p5subset.xml"/> And that's all great, I get back my tables. BUT I don't have the tableDecoration attributes (@role, @rows, @cols) because those are in the "tei" module, and they've been stripped from the EpiDoc compiled ODD because there are no references to the att.tableDecoration class in it (because it excludes table). This means I have to do <moduleRef key="tei" source="../../TEIC/TEI/P5/p5subset.xml"/> as well, so I get that attribute class back. So...interesting gotcha, which leads my to ask why att.tableDecoration is in "tei" instead of "figures". Is that just a mistake? On Fri, Oct 7, 2016 at 1:07 PM, Lou Burnard wrote:

moduleRef already has @source, I think.

But there's still something wrong. I ought to be able to do something like :

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <elementSpec ident="list" mode="delete" module="core"/> </schemaSpec>

to get an even barer version from which <list> is missing. But no, I always get a schema with no elements at all.

On 07/10/16 17:34, Hugh Cayless wrote:

...

I expect that would work, yeah. I think what you really want though is to be able to pull a moduleRef off a different @source. What if we let you use @source on moduleRef as well?

On Fri, Oct 7, 2016 at 12:29 PM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

Yes, that does seem to be the problem (James is saying the same thing in

...

another window).

It doesn't seem unreasonable to want to start from an existing ODD and then add some more declarations or modules to it. An ODD processor has to be able to reconcile multiple spec elements anyway. I wonder if it would work if I just copied the specs from the tagdocs module into my new ODD?

On 07/10/16 17:22, Hugh Cayless wrote:

My guess would be this is because tei_bare doesn't include tagdocs. So

...

you're referencing a module that doesn't exist, as far as it's concerned?

If this is how it works, then you can only ever subset chained ODDs, not restore already-filtered stuff, which means it would actually be unusable for my own current purpose—basing a critical editions ODD on EpiDoc, because we want to put back some stuff EpiDoc removes. That's kind of a bummer. Maybe we need to think about how we'd want chaining to work, and then figure out how to make that happen instead?

On Fri, Oct 7, 2016 at 11:28 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

I am having trouble getting odd chaining to work at all.

...

Can anyone explain to me why the following doesn't do what I expect?

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="tagdocs"/> </schemaSpec>

(The file tei_bare.subset.xml is one I produced by running the published ODD for tei_bare through teitoodd)

In my mind, this ought to give me a schema which contains the same as tei_bare plus the elements defined in the tagdocs module. In fact it gives me a schema with no elements at all.

I must be missing something obvious. Maybe someone could send me an example of an ODD chaining which does work?

On 06/10/16 16:37, Hugh Cayless wrote:

I was playing around last night with chaining ODDs and thinking we needed

...

better documentation for them, so this is a nice start. One thing that tripped me up last night is that it isn't clear that @source has to point at a *compiled* ODD, so you can't just point at the latest EpiDoc ODD, for example, you have to run it through teitoodd first. I can see why that's so, but wonder if there's any way around it...

On Thu, Oct 6, 2016 at 11:28 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

On my way home from Vienna I started drafting a little homily about how to

update your old ODD to a pure new shiny one. The source is in github > under > TEI/Documentation/pureODD/purifyDoc.xml > > CETEICEAN renders it reasonably well (modulo a couple of gotchas on > which > I've posted issues) at http://teic.github.io/TCW/purifyDoc.html, but > the > nicest reading version is at http://teic.github.io/TCW/puri > fyDoc_static.html > > I'd very much welcome Council's comments before exposing it further. > Seems to me we need to promote ODD a bit more, and this might be a > good > start. I'm also working on an "ODD for beginners" guide, but this one > is > aimed at old lags who made an ODD back in the day and are interested > in > getting up to speed with its new possibilities. So much so (I now > realise) > that I've completely forgotten to mention the existence of Roma in > it. > But > I'll stop tweaking for now anent your comments... > > > -- > 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 20/10/16 17:57, Lou Burnard wrote:

On 20/10/16 15:42, Hugh Cayless wrote:

...

Lou, is that your whole ODD? If so, I think the problem may be that you still need to put moduleRefs in the derived ODD. You don't seem to get them for free from the source.

Yes, that's my whole ODD. So even in an expanded ODD, each elementSpec has lost information about which module it came from? That seems weird. Are you saying that in order to delete an element (say list) from a chained odd I have to specify it like this:

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="core" except="list" source="p5subset.xml"/> </schemaSpec>

Why doesn't that get me all the other core elements again?

You shouldn't have to have a @source on the moduleRef. The second ODD works, or should work IMHO, precisely the way a normal ODD does with respect to p5subset. If you are pointing at tei_bare.subset.xml then if you do <moduleRef key="core" except="list"/> You should get p, item, label, head, author, and title (since those are in bare). This is why the DTA version that SusanneH was working on has its customisation first have a maximal ODD, and then the different types of ODD further refine that. (i.e. get rid of the msDesc stuff cuz one of theirs is about print, or get rid of other stuff.)

This means I have to do

...

<moduleRef key="tei" source="../../TEIC/TEI/P5/p5subset.xml"/>

as well, so I get that attribute class back. So...interesting gotcha, which leads my to ask why att.tableDecoration is in "tei" instead of "figures". Is that just a mistake?

Possibly. The idea was to define all the attribute classes in one place, so that they were available to any element that wanted them. I agree that att.tableDecoration does seem sort of more useful to tables than anything else.

Could you post somewhere some discussion of your experiments in ODD chaining, so that I can steal it to enrich my tutorial ?

I didn't think the processing was there to include back in elements which had been excluded by the subset you are pointing at, only further refine. (If so, nifty, and I guess that is the way to do it.) Susanne and I had some tentative plans to document this more somewhere. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

The way I was thinking about it: every ODD has to declare the modules it's using. Aren't moduleRef/@exclude and elementSpec/@mode='delete' basically equivalent anyway? On Thu, Oct 20, 2016 at 1:19 PM, Lou Burnard wrote:

On 20/10/16 18:11, James Cummings wrote:

...

On 20/10/16 17:57, Lou Burnard wrote:

...

On 20/10/16 15:42, Hugh Cayless wrote:

...

Lou, is that your whole ODD? If so, I think the problem may be that you still need to put moduleRefs in the derived ODD. You don't seem to get them for free from the source.

Yes, that's my whole ODD. So even in an expanded ODD, each elementSpec has lost information about which module it came from? That seems weird. Are you saying that in order to delete an element (say list) from a chained odd I have to specify it like this:

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="core" except="list" source="p5subset.xml"/> </schemaSpec>

Why doesn't that get me all the other core elements again?

You shouldn't have to have a @source on the moduleRef. The second ODD works, or should work IMHO, precisely the way a normal ODD does with respect to p5subset. If you are pointing at tei_bare.subset.xml then if you do

<moduleRef key="core" except="list"/>

You should get p, item, label, head, author, and title (since those are in bare).

OK, but I hope you can see why I am puzzled. If I want to suppress an element from a non-chained ODD (or one chained from p5subset) I can do it by saying "elementSpec mode="delete". If I'm working further down the chain, I can't : I have to use a moduleRef.

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

Well, I think if you had a moduleRef, then you could delete it with an elementSpec, you just can't use the elementSpec without the moduleRef. I think tests and better documentation of this would be a grand idea. Sent from my phone.

On Oct 20, 2016, at 13:43, Lou Burnard wrote:

...

On 20/10/16 18:23, Hugh Cayless wrote: The way I was thinking about it: every ODD has to declare the modules it's using.

Aren't moduleRef/@exclude and elementSpec/@mode='delete' basically equivalent anyway?

Yes. Which is why I am puzzled that one works and the other doesn't.

I suggest it might help to create a little test suite... -- 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

Lou, Can't you use in your chained ODD? It was certainly *intended* that you should be able to do that, just like you can further refine it to add a attdef/valList or whatever. -James On 20/10/16 18:19, Hugh Cayless wrote:

Yeah, what James said, you don't need @source on your moduleRef--it's inherited from the one on schemaSpec.

Mine is maybe a unique circumstance, but it strikes me that this is actually a pretty powerful way to assemble customizations from multiple sources. I haven't written it up yet, but plan to...

On Thu, Oct 20, 2016 at 1:11 PM, James Cummings wrote:

...

On 20/10/16 17:57, Lou Burnard wrote:

...

On 20/10/16 15:42, Hugh Cayless wrote:

...

Lou, is that your whole ODD? If so, I think the problem may be that you still need to put moduleRefs in the derived ODD. You don't seem to get them for free from the source.

Yes, that's my whole ODD. So even in an expanded ODD, each elementSpec has lost information about which module it came from? That seems weird. Are you saying that in order to delete an element (say list) from a chained odd I have to specify it like this:

<schemaSpec ident="ODDauthoring" source="tei_bare.subset.xml" > <moduleRef key="core" except="list" source="p5subset.xml"/> </schemaSpec>

Why doesn't that get me all the other core elements again?

You shouldn't have to have a @source on the moduleRef. The second ODD works, or should work IMHO, precisely the way a normal ODD does with respect to p5subset. If you are pointing at tei_bare.subset.xml then if you do

<moduleRef key="core" except="list"/>

You should get p, item, label, head, author, and title (since those are in bare).

This is why the DTA version that SusanneH was working on has its customisation first have a maximal ODD, and then the different types of ODD further refine that. (i.e. get rid of the msDesc stuff cuz one of theirs is about print, or get rid of other stuff.)

This means I have to do

...

...

<moduleRef key="tei" source="../../TEIC/TEI/P5/p5subset.xml"/>

as well, so I get that attribute class back. So...interesting gotcha, which leads my to ask why att.tableDecoration is in "tei" instead of "figures". Is that just a mistake?

Possibly. The idea was to define all the attribute classes in one place, so that they were available to any element that wanted them. I agree that att.tableDecoration does seem sort of more useful to tables than anything else.

Could you post somewhere some discussion of your experiments in ODD chaining, so that I can steal it to enrich my tutorial ?

I didn't think the processing was there to include back in elements which had been excluded by the subset you are pointing at, only further refine. (If so, nifty, and I guess that is the way to do it.) Susanne and I had some tentative plans to document this more somewhere.

-James

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

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

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford