Re: [tei-council] purifying odd doc

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