TODO

* Download compiled ODD option
 
Syd Bauman:

1. The "Filename" field on the customization page seems to accept
   most anything typed there. Entering strings that have slashes,
   back slashes colons, or whitespace are all likely to cause
   problems on some system or other for the filename. But moreover,
   this value is the value of ident= of <schemaSpec>, and therefore
   has to be a data.name, i.e. an xsd:Name. It should be checked
   immediately when the user clicks "Submit" on the "Customize your
   customization" page. (Similarly the new "Prefix for TEI pattern
   names in schema" field.)

2. On the page for editing attributes (also used for adding a new
   attribute, and thus I gather named "Add some attributes") the
   "List of values" field has similar problems. It permits anything
   to be entered, the result of which may not be at all what the user
   intended, and often results in an invalid ODD file. More on the
   datatype problems here in a subsequent mailpiece. But for now, I
   think Roma should do something a bit more intelligent. The
   error-checking should occur up front. My first-cut suggestion is: 
   * a value stuck onto ident= of <valItem> and thus into the
     schema should be an xsd:Name.
   * Roma should either
     - parse the string the user sticks in on any non-xsd:Name
       characters (I.e., "red, white,and blue are the colors/of
       the Union,Jack!" should result in
          red     white  and
          blue    are    the
          colors  of     the
          Union   Jack
       with no errors.)
     - expect a whitespace-separated string of xsd:Names, and
       complain if there's anything else (I.e. the above string
       gives an error, as does "This is 4you"; whereas "This is
       for you" results in
          This  is  for  you
       with no errors.)

4. A *lot* more on-screen documentation is in order. (E.g., the
   existence of both the the drop-down menu and the type-in box in
   the "Contents" field of the "Add Element" page seems quite
   confusing. I can perhaps provide more examples later, but gotta go
   now.)

5. I doubt you can fix it, but everyone complains about losing stuff
   when after having slected elements on the "Change module" page,
   and clicking something other than "Submit Query".

Peter Boot:

6. sometimes the buttons reflow too (Firefox on Windows, 1024 * 768),
   which looks a bit silly.

James Cummings:

7. The Add elements tab (and modifying class) has a 'Submit Query'
   button with white background, most others are red.

8. Oh, that and you use that ugly pale blue for the tabs which you
   also use for the TEI Website/Guidelines border.
   e.g. http://www.tei-c.org/P5/Guidelines/SG.html

   Marketing people would tell you that a darker colour of blue indicates
   reliability, trustworthiness, and all those things that the TEI might
   want to be seen as.  That colour of blue always just makes me think of
   Miami Vice.  Just a personal opinion mind.

Michael Beddow:

10.  I see the members field in the element class information on screen display
tables is still not being populated. You'll recall that we corresponded a
bit about the fact that this population works for document generation to an
html output file but not when apparently the same xslt is called to create a
screen display. I'm afraid I drew a blank trying to figure out why, except
that is seems to be somehow Cocoon related (a bit more specifically, Cocoon
resource-path-resolution related). On my local installation, where I do the
ODD source lookups to the REST i/f of the "standalone" eXist server, the
"members" field gets duly populated, and with working hyperlinks, without my
making any adjustments either to the XSLT or the PHP. Which is why I think
something Cocoonish is involved.


11. I also like the clarification of  the erstwhile "Save" label to "Save
Customization"  Might it be worth expanding "Change Classes" to read "Change
Attribute Classes"?  I ask because, as a recent posting tends to suggest,
that label rather tends to send people off on the wrong track when what they
aspire to do is alter a content model. The absence of element classes in the
display ought, I suppose, to encourage them to think again about what they
really want to accomplish and how, but I fear it is equally likely to lead
them to conclude that it can't be done via this interface at all, leading
them to resort to manual ODD-hacking with blunt instruments.

Syd:

* When a class has no members, its reference documentation is
  (appropriately) not printed out. But references to it, including
  its table of contents entry, still are.

* In the TOC the headings "Classes", "Elements", and "Macros" neither
  match nor link to the corresponding headings in the main part.

* The first child of the resulting HTML <div class="specifications"
  id="body.1_div.1"> is an <h2> element with the content "1". I'm not
  sure in what series of what things this is the first, but it
  certainly looks a bit weird.

* I still think wrapping individual entires in the TOC with <div>
  rather than <p>, <span>, or even nothing, is nuts.

* The HTML reference documentation claims to be XHTML, but is
  invalid: 
  - <ul> element with class=toc that has no content
  - <span>s with xml:id= instead of id= [In all fairness, these
    result from <note type="cit"> elements that Lou & I decided to use,
    but probably never told you about :-]
  And it doesn't have an XML declaration.

Lou:
 * if an <elementSpec mode="change"> appears twice in the ODD,
   how do we trap that and signal an error?

James:
- When I deleted an attribute from an element, the generated ODD also makes it
look like I've renamed all its other attributes.  I'm guessing this is because
it is hard to check each of these to see if I've really renamed them on the
form, or track the webform changes.  This actually enabled me to generate an
invalid RNC which complained about multiple definitions of xml:id or something
similar, and hand editing to remove the non-renamings stopped this.
- Whenever I am on a screen changing attributes for an element, I have no way of
knowing what element's attributes I am changing.  (i.e. it doesn't appear on the
screen, and I have a memory like a sieve.)
- Whenever I am on a screen changing attributes for a class, the same is true.
- I had no way to edit macro.paraContent
- 'Change Classes' should be 'Change Attribute Classes' since I don't seem to be
able to change model classes here.