The problem isn't the datatype of @hand, but the datatype of valItem@ident The kosher way of doing this would be to define a <handNotes> element in the header or some other document and validate references to the <handNote>s within it using XSLT <!-- in the header --> <handNotes> <handNote xml:id="pbs">Percy's scrawl</handNote> <handNote xml:id="mws">Mary's scrawl</handNote> </handNotes> <!-- in the text--> <line hand="#pbs">Perce wuz ere </line> If you have one header and lots of documents, you could use xml:base to reduce the verbosity of the @hand values. Or use a private URI in conjunction with a prefixDef <!-- in the instance header --> <prefixDef ident="sga" matchPattern="([a-z]+)" replacementPattern="../corphusHdr.xml#$1"> <p> Private URIs with the prefix "sga" point to elements in the project's global corpus header </p> </prefixDef> <!-- in the document --> <line hand="sga:pbs">Perce wuz ere </line> On 06/02/16 01:28, Raffaele Viglianti wrote:
Hi Lou, thanks for your comments!
In the following case, we have restricted the values of @hand to a set number of IDREFs that we know are correct; so that the encoders don't misspell them or add unwanted ones:
<attDef ident="hand" mode="replace" usage="opt"> <valList mode="replace" type="closed"> <valItem ident="#pbs"/> <valItem ident="#mws"/> <valItem ident="#library"/> </valList> </attDef>
Since @hand as datatype of data.pointer, those strings will match the datatype. Is there a more kosher way of doing this?
Other fairly non-sensical values with [ (, etc will be gone in a future iteration.
Raff
On Fri, Feb 5, 2016 at 5:53 PM, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Raff
I noticed the following problems in your ODD
(a) several of your valList/valItem/@ident values are not valid XML names (e.g. they include characters like # or [ or ') : this doesnt matter to RELAXNG, but it makes life difficult for other processors
(b) Your redefinition of the <line> element includes the <add> element twice. Once will do.
(c) the problem with list is a nasty one. you've undeclared some elements which the default content model expects to find, leaving behind multiple sequences of 0:n model.globals. Probably the easiest solution is to redefine the content model for <list>. I'll think about that and get back to you...
Lou
On 05/02/16 22:18, Raffaele Viglianti wrote:
The "cos-nonambig" error is still there :(
On Fri, Feb 5, 2016 at 5:07 PM, Lou Burnard <lou.burnard@retired.ox.ac.uk wrote:
Excellent! Did the "cos-nonambig" error just disappear or have you not
tested for that?
On 05/02/16 22:05, Raffaele Viglianti wrote:
Thanks! Ok, everything is in PureODD now and all files validate.
Raff
On Fri, Feb 5, 2016 at 4:38 PM, Lou Burnard < lou.burnard@retired.ox.ac.uk wrote:
<dataRef name="string" restriction="indent\d"/>
On 05/02/16 20:24, Raffaele Viglianti wrote:
Hi Lou,
> I'm trying to redefine our datatypes in pure ODD, but one of them > uses a > regex: > > <content> > <rng:choice> > <rng:value>right</rng:value> > <rng:value>center</rng:value> > <rng:value>left</rng:value> > <rng:data type="string"> > <rng:param name="pattern">indent\d</rng:param> > </rng:data> > </rng:choice> > </content> > > I understand I can use <valList> for the first three values, but what > about > the last one? > > Thanks, > Raff > > On Fri, Feb 5, 2016 at 12:15 PM, Lou Burnard < > lou.burnard@retired.ox.ac.uk> > wrote: > > Come come you're too modest : what about that thing called um, what > was > > it, dimple, or pimple, or something? >> >> On 05/02/16 16:03, Magdalena Turska wrote: >> >> I'm a bit ashamed but indeed I do not have ODDs of my own to test. >> >> On 5 February 2016 at 15:56, Raffaele Viglianti < >>> raffaeleviglianti@gmail.com >>> >>> wrote: >>> >>> Hi Lou, >>>> I converted the Shelley Godwin Archive ODD to PureODD last week. >>>> Sorry >>>> for >>>> not following up sooner. >>>> >>>> The ODD is here: >>>> >>>> >>>> >>>> >>>> >>>> https://github.com/umd-mith/sga/blob/master/data/odd/shelley-godwin-page.odd >>>> >>>> Everything seems to work fine, but I have two comments / questions: >>>> >>>> 1) Datatypes (macroSpec[@type='dt']) are still defined in RNG, >>>> correct? >>>> We >>>> define some custom datatypes in our ODD and I still had to use RNG >>>> >>>> 2) The XSD that gets generated returns a "cos-nonambig" error on >>>> tei:list. >>>> We don't touch tei:ist in the ODD however. We have always only >>>> generated >>>> RNG, so I'm not sure whether this problem is new (ie caused by Pure >>>> ODD, >>>> or >>>> it's always been there) >>>> >>>> I hope to find the time to give a stab at the MEI ODD too (that >>>> will >>>> be >>>> fun), but I will need a converter script there, because it's a >>>> *huge* >>>> ODD. >>>> >>>> Raff >>>> >>>> >>>> On Fri, Feb 5, 2016 at 6:29 AM, Lou Burnard < >>>> lou.burnard@retired.ox.ac.uk> >>>> wrote: >>>> >>>> I haven't heard from anyone since I asked Council members to check >>>> that >>>> >>>> their existing ODDs continue to work as expected using the >>>> >>>>> lb42-pureodd >>>>> branch. So maybe no Council members actually have any ODDs to >>>>> check, >>>>> or >>>>> maybe those who do have all checked and have nothing to report, or >>>>> maybe >>>>> they just haven't got round to it yet. I don't know, but just in >>>>> case >>>>> >>>>> it's >>>>> >>>>> the 3rd possibility, please could I urge you to give it a go this >>>> weekend? >>>>> If you prefer, you could just bung me a copy of the ODD and I'll >>>> test >>>> >>>> it >>>>> for you! >>>>> >>>>> Why the pressure? Well, mostly that I've just been reminded that >>>>> we're >>>>> aiming for a pre-release freeze for the end of the current month, >>>>> and >>>>> I'm >>>>> going to be buried in the French countryside with only >>>>> intermittent >>>>> net >>>>> access until then. >>>>> >>>>> >>>>> -- >>>>> 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