New subject: dataSpec content

2 Feb 2019

      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  on behalf of Syd Bauman 
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

Re: [Tei-council] dataSpec content

James Cummings

Mylonas, Elli

Raffaele Viglianti

tags

participants (3)