OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: "Carl Hage" <carl@chage.com>
  • To: "Xml-Dev (E-mail)" <xml-dev@ic.ac.uk>
  • Date: Sun, 19 Jul 1998 11:26:39 -0800

> Date:          Sat, 18 Jul 98 15:02:57 UT
> From:          "Simon St.Laurent" <SimonStL@classic.msn.com>
> <!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@chage.com> 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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS