#137 "Add new attribute" errors, etc.

ROMA
open
5
2012-09-15
2009-11-14
Ian Rons
No

In the "Add a new attribute" page:

* With respect to the "Closed list?" radio buttons, it seems impossible to change the value from "yes" to "no".
* When there is a list of possible attribute values in the "List of values" input box, if the input box is cleared of its contents and the form submitted, the values in the list remain unchanged and are not deleted as expected.
* Atttributes entered in the "List of values" input box, delimited by commas, are not trimmed to remove surrounding whitespace. e.g., entering "valueOne, valueTwo, valueThree" will produce attribute values "valueOne", " valueTwo", " valueThree".

Additionally, with, e.g., the element <add>, this element should inherit (in tei_all.rng) some attribute classes such as att.editLike and att.responsibility, but these don't show up.

Furthermore, adding pointer-type attribute values in the "List of values" such as "#handOne", "#handTwo", etc., produces the following schema errors:

Your schema is not valid!!
DOMDocument::relaxNGValidate() [function.DOMDocument-relaxNGValidate]: Type Name doesn't allow value '#handOne'
DOMDocument::relaxNGValidate() [function.DOMDocument-relaxNGValidate]: Element valItem failed to validate attributes
DOMDocument::relaxNGValidate() [function.DOMDocument-relaxNGValidate]: Type Name doesn't allow value '#handTwo'
DOMDocument::relaxNGValidate() [function.DOMDocument-relaxNGValidate]: Element valItem failed to validate attributes

I am also seeing illegal character errors in OxygenXML when generating a schema, where (it seems) documentation text is being placed inside <define/>, whilst a copy of this text is also being placed (correctly, I presume) inside the <a:documentation/> element.

I'm also having trouble editing text inside some HTML <textarea> elements of the Roma web-interface, in particular on the "Customize" page it seems necessary to first delete all the text, submit the form and then type your new text, otherwise it simply appends the replaced text to the end of the default text. Additionally, on the "Defining a new element" page, the "Description" <textarea> doesn't seem to apply changes when the form is submitted.

Discussion

  • I'll start looking at these. Some may be easy to solve.

    Can you give a test for how to reproduce "I am also seeing illegal character errors in OxygenXML when generating a schema, where (it seems) documentation text is being placed inside <define/>"?

     
  • Ian Rons
    Ian Rons
    2009-11-15

    Apologies, but I can't seem to reproduce that problem. All I have is this from a generated RNG file:

    <define name="att.ascribed.attribute.who" xmlns="http://relaxng.org/ns/structure/1.0"
    ><optional><attribute name="who" xmlns="http://relaxng.org/ns/structure/1.0"
    xmlns:sch="http://purl.oclc.org/dsdl/schematron"><a:documentation
    xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
    >indicates the person, or group of people, to whom the element content is ascribed.</a:documentation><list><oneOrMore><data type="anyURI" />
    </oneOrMore>
    </list>
    </attribute>
    </optional>indicates the person, or group of people, to whom the element content is ascribed.</define>

     
  • I am also noticing (again on the "Add a new attribute" page) that if one types in a few values for the attribute and makes it a closed list, the produced schema does not enforce that closed list. However, if one makes it a required attribute, the closed list of values is enforced in the schema.

     
  • Ian Rons
    Ian Rons
    2009-12-08

    I believe the schema errors (produced when defining a list of possible values for a given attribute) are not a Roma bug, but rather stem from the definition of @ident in <valItem>, which is currently a member of the attribute class att.identified. This inappropriately limits the value to the datatype data.name (= an XML name), but many attributes use other datatypes which are not so restrictive (e.g., data.pointer in the example given above) and these all produce schema errors.

    The solution is, I suppose, to submit this as a TEI bug, requesting a change to <valItem> to allow @ident to accept CDATA, possibly involving a rename of @ident itself. This is a bit beyond my level of knowledge of XML/TEI, and I'm not sure of the protocol here, but I'll submit this as a bug if you agree.

     
  • Ian Rons
    Ian Rons
    2009-12-22

    A few more points to note...

    At present, attribute classes are still listed even if their parent module has been deleted.

    It would be nice to have the ability to remove entire attribute classes.

    It would also be good to be able to remove an element's membership of an entire attribute class. ODD files imported into Roma which use this method aren't processed properly.

    It would be nice if attributes could be listed by inheritance rather than seemingly in random order on the per-element "List of attributes" page.

    In "Change Classes"->"changeAttributes", there is no title, but where it should be it just has "List of attributes: " without printing the class name.

     
  • I have not been able to look at this yet, so I am marking it as being at risk

     
    • milestone: 871215 --> 871212
     
  • Lou Burnard
    Lou Burnard
    2012-09-15

    • milestone: 871212 --> ROMA