[
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)
|