[tei-council] Re: webRoma

Syd Bauman Syd_Bauman at Brown.edu
Tue Mar 27 11:09:50 EST 2007


> I'm also quite sure I had some problem with an attribute last week,
> but for the life of me I can't remember what it was. 

Ah! That's what it was. webRoma will generate <classSpec> elements
that do not have (the required) type= attribute.


While we're talking about webRoma, one of the things I really feel
needs to be improved is the interface to <valList> & data.enumerated.
At the very least when an ODD is read in, the "List of values" field
on the "Add a new attribute" page (which is often used for changing
attributes) should be pre-populated with the values found in the
existing <valList>. Also the "Closed list" question should probably
include all three possibilities, no? ("closed", "open", and "semi").

Lastly, although to my knowledge we have still not entirely
straightened the data.enumerated vs. valItem/@ident issue, I think
(perhaps incorrectly) that we are still of the opinion that <valList>
should only be used in combination with certain datatypes[1]. If
there are datatypes with which we feel a value list should not be
specified (data.count jumps to mind), I think the webRoma front-end
should reflect this.

Note
----
[1] The GLs currently use <valList> in conjunction with:
    13 data.truthValue
     1 data.xTruthValue
     1 data.certainty (not including precision= of <date>, which is
                       about to be removed)
    70 data.enumerated
     1 data.name, w/ maxOccurs=5, which is for generate= of
                  <classSpec>, and which I claim is in error: should
                  be data.enumerated.
    Are there any other datatypes with which <valList> makes a lot of
    sense? (To be honest, I'm not very convinced of truthValue,
    xTruthValue, and certainty -- seems to leave open the possibility
    for discrepancy.) 




More information about the tei-council mailing list