duplicate @rend error in generated RNG schema
I was just bitten by the side effect of moving @rend to att.global.rendition. In taking an old and perfectly fine TEI ODD, and generating a fresh schema from it, the RNG was invalid because of a duplicate definition of @rend. Changing it so that I modified @rend on att.global.rendition rather than att.global solved this. Took me a good 10 minutes staring at it to realise what was wrong. doh. I'm just mentioning it to put it in the back of your brain in case anyone asks in the future. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Been there done that, Sigh. Sent from my Samsung Galaxy Tab®|PRO -------- Original message -------- From: James Cummings Date:05/19/2015 19:29 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: [tei-council] duplicate @rend error in generated RNG schema I was just bitten by the side effect of moving @rend to att.global.rendition. In taking an old and perfectly fine TEI ODD, and generating a fresh schema from it, the RNG was invalid because of a duplicate definition of @rend. Changing it so that I modified @rend on att.global.rendition rather than att.global solved this. Took me a good 10 minutes staring at it to realise what was wrong. doh. I'm just mentioning it to put it in the back of your brain in case anyone asks in the future. -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
On 15-05-19 11:29 AM, James Cummings wrote:
I was just bitten by the side effect of moving @rend to att.global.rendition. In taking an old and perfectly fine TEI ODD, and generating a fresh schema from it, the RNG was invalid because of a duplicate definition of @rend. Changing it so that I modified @rend on att.global.rendition rather than att.global solved this. Took me a good 10 minutes staring at it to realise what was wrong. doh.
I'm just mentioning it to put it in the back of your brain in case anyone asks in the future.
I've been bitten by it too, and I was the once who made the change. :-) I think any significant change to class structures like this will generate similar problems. I have tried to think of a way around this, but the only approach I can think of involves specially-coded traps in the schema creation process, and that's a bit ungainly. We could add Schematron rules to apply to the ODD, but for that to work, you would need to be validating your ODD against a fresh TEI schema at some point. Would that have worked for you in this case? Cheers, Martin
On 19/05/15 20:51, Martin Holmes wrote:
I've been bitten by it too, and I was the once who made the change. :-) I think any significant change to class structures like this will generate similar problems. I have tried to think of a way around this, but the only approach I can think of involves specially-coded traps in the schema creation process, and that's a bit ungainly. We could add Schematron rules to apply to the ODD, but for that to work, you would need to be validating your ODD against a fresh TEI schema at some point. Would that have worked for you in this case?
It would indeed have worked for me. I was at work so subscribed to the draft oxygen-tei framework created with the most recent TEI. So if you had added a schematron rule that a classSpec with @ident of att.global that has a valList for @rend inside it should show a warning that it should be att.global.rendition, then I'd probably have noticed quicker. :-) Probably. Seems a reasonable schematron warning to add, but I'd only want this to be a warning because I could, for example, delete @rend on att.global.rendition and make a brand new @rend on att.global, for some bizarre reason, and this should technically be legal, no? -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
I've created a ticket which perhaps we can discuss at the FtF: https://sourceforge.net/p/tei/bugs/754/ Cheers, Martin On 15-05-20 02:37 AM, James Cummings wrote:
On 19/05/15 20:51, Martin Holmes wrote:
I've been bitten by it too, and I was the once who made the change. :-) I think any significant change to class structures like this will generate similar problems. I have tried to think of a way around this, but the only approach I can think of involves specially-coded traps in the schema creation process, and that's a bit ungainly. We could add Schematron rules to apply to the ODD, but for that to work, you would need to be validating your ODD against a fresh TEI schema at some point. Would that have worked for you in this case?
It would indeed have worked for me. I was at work so subscribed to the draft oxygen-tei framework created with the most recent TEI. So if you had added a schematron rule that a classSpec with @ident of att.global that has a valList for @rend inside it should show a warning that it should be att.global.rendition, then I'd probably have noticed quicker. :-) Probably. Seems a reasonable schematron warning to add, but I'd only want this to be a warning because I could, for example, delete @rend on att.global.rendition and make a brand new @rend on att.global, for some bizarre reason, and this should technically be legal, no?
-James
participants (3)
-
James Cummings -
Lou Burnard -
Martin Holmes