-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default att values incorrectly processed by Roma web app #1213
Comments
does this equally apply when you construct an ODD by hand? that is, if you Original comment by: @sebastianrahtz |
A hand-written ODD in which no new <defaultVal> is specified to replace an existing one should reasonably expect the existing default to continue to apply, if the parent <attDef> is being processed in mode CHANGE. The bug I am reporting here is that web roma does not display an existing defaultVal so the user has no way of telling they are about to shoot themselves in the foot. In the long term of course the correct solution is to deprecate and remove <defaultVal> passim as previously noted. Original comment by: @lb42 |
Original comment by: @sebastianrahtz |
This issue was originally assigned to SF user: rahtz |
moved to TEIC/Roma-Antiqua#21, closing here |
When an attribute has a specific default value in the ODD source, and the user attempts to change the value list for it using web roma, the form does not display the existing default value. Consequently, the user has no way of knowing that it exists, and may easily supply a list of attribute values which do not include it, thus generating an invalid DTD or XSD schema. Tested this with <list> which retains the default "simple" even though it does not appear on the screen.
Original comment by: @lb42
The text was updated successfully, but these errors were encountered: