If I understand Raff's suggestion correctly, then I would support the restrictive approach to only allow users possibilities of making dataTypes that 'Make Sense'. If they want to do something so weird as put an elementRef into the content of a dataSpec then they clearly should understand it well enough to be hand-editing their ODD, and then explain to us why it should be allowed in RomaJS. (But generally, RomaJS doesn't have to do everything that is possible, but only what we recommend people do.)

Many thanks,

James 

--

Dr James Cummings, James.Cummings@newcastle.ac.uk
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University

---

From: Tei-council <tei-council-bounces@lists.tei-c.org> on behalf of Syd Bauman <s.bauman@northeastern.edu>
Sent: 02 February 2019 12:04
To: lou.burnard@retired.ox.ac.uk; TEI Council
Subject: Re: [Tei-council] dataSpec content

 

[Trying to channel Raff, who is probably still asleep.]

1. Actual content model (that Raff was discussing -- i.e., a model
against which all of our current dataSpec/content elements are
valid):

   ( dataRef* | valList | textNode | aDr | avL | atN )
   aDr = element alternate { dataRef* }
   avL = element alternate { valList }
   atN = element alternate { textNode }


2. No, Raff was not suggesting any change to content models, only to
his user interface in RomaJS.

But now that you point it out, it would probably make sense to
disallow at least <empty>, <anyElement>, <elementRef>, & <classRef>,
and probably even <macroRef> from the <content> of a <dataSpec>.

> Firstly, I dont understand your pseudocode content model.  Does it
> mean the same as the following:
>
> <alternate minOccurs="1" maxOccurs="undefined">
>    <elementRef key="dataRef"/>
>    <elementRef key="valList"/>
>    <elementRef key="textNode"/>
> </alternate>
>
>
> Are you proposing to change the current content model of <content>
> or of <dataSpec> ?
>
> In either case, I suggest defining a class model.dataSpecPart might
> help.
>
> Or is it just about how selective your interface should be in what
> it permits, perhaps as a not-so-subtle way of avoiding the
> question?
>
> Current practice in defining dataSpecs is constrained by what was
> done in P4: I re-used the <content> element here because we also
> used it to define the expansion of macroSpecs (i.e parameter
> entities) back in the day, but that's a historical explanation.
> This over-generates, as you rightly say: it's not at all clear what
> it might mean to put e.g. an elementRef into the content of a
> dataSpec!
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council

_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council