Altova Mailing List Archives


Re: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5

From: "Carl Hage" <carl@-----.--->
To: "Xml-Dev (E-mail)" <xml-dev@--.--.-->
Date: 7/19/1998 9:06:00 PM
> Date:          Sat, 18 Jul 98 15:02:57 UT
> From:          "Simon St.Laurent" <SimonStL@c...>
> <!ATTLIST XSC:AttDef
>     Name NMTOKEN #REQUIRED
>     Element NMTOKEN #IMPLIED
>     id ID #IMPLIED
>     Type (CData |
>     ID |
>     IDRef |
>     IDRefs |
>     Entity |
>     Entities |
>     Nmtoken |
>     Nmtokens |
>     Notation |
>     Enumerated) "CData"
>     Required (Yes | No) "No"
>     Fixed (Yes | No) "No"
>     Enumeration NMTOKENS #IMPLIED
>     AttValue CDATA #IMPLIED>

Moving the multiple element choice into the Type attribute was a big 
improvement. Without this, any software processing the AttDef would have to 
scan all the elements and rederive an enum type. It's a real pain to model 
"What is the type of the attribute" as the existence of one of a set of 
attributes, and wouldn't fit how the attribute would be extended.

However, moving <EnumerationValue>+ into a token string creates a severe 
problem. It's impossible to add information associated with each code value, 
for example documentation on the semantics for each. Also, it may be common 
to import enumeration values defined within an external standard, e.g. by 
using xml links.

To correct the problem, simply add <EnumerationValue> back in, e.g.
<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?, XSC:EnumerationValue*)>

Though it's not as important for AttValue to be an element, I think for 
improved extensibility and the ability to attach documentation, <AttValue> 
should be restored, with Doc? added, e.g.

<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?, XSC:EnumerationValue*, 
XSC:AttValue?)>

<!ELEMENT XSC:AttValue Doc?>

It would also be better to rename this, say to:
<!ELEMENT XSC:DefaultValue Doc?>

which has the possiblility of analogous use in specifying element values. 
(XML data has a nice feature in using common parts to describe values for 
attributes and elements.)

It may be important to associate other information (including xml links) with 
the NMTOKEN used for the DefaultValue. You are almost hosed (need to pervert 
extentions to the AttDef) if the value is not supplied in a separate element.

What happened to NotationValue? Since it's a reference within the document, 
it's not necessary to add documentation, but it seems better to represent a 
list as elements rather than space separated names in a string. You should 
probably use:

<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?, 
                      (XSC:NotationValue*|XSC:EnumerationValue*), 
                      XSC:AttValue?)>

for <!ATTLIST XSC:NotationValue Notation IDREF #REQUIRED>
I believe, the IDREF must match an ID attribute and be unique across the ID 
attributes in all elements in the document. That means this is not the 
notation Name, which isn't ID. Tbus it probably should be a NMTOKEN.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@c...> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.