Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Sun, 12 Jul 98 15:09:37 UT
At long last, here is the revised Attribute Declarations section. Note that
it provides for attributes to be declared outside of XSC:ElementDecl elements,
and uses attributes instead of child elements to make its declarations. I
also gave XSC:AttDef an id attribute.
This draft underwent some drastic changes based on XML-Dev discussions; I'm
suspecting that there are more mistakes in here than usual. Please read it
closely. There are some changes in other sections that need to be made, like
Name vs. name as an attribute for XSC:ElementDecl.
As always, a prettier HTML version of this will be posted shortly at
Dynamic HTML: A Primer / XML: A Primer / Cookies
2.4 Attribute Declarations
Attribute declarations are made with empty XSC:AttDef elements. XSC:AttDef
elements may be nested inside of XSC:ElementDecl element declarations or
linked to element. The data type of an attribute is defined with an attribute,
as is a declaration of whether or not it is required and a possible default
<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More)>
Name NMTOKEN #REQUIRED
Element NMTOKEN #IMPLIED
id ID #IMPLIED
Type (CData |
Required (Yes | No) "No"
Fixed (Yes | No) "No"
Enumeration NMTOKENS #IMPLIED
AttValue CDATA #IMPLIED>
In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested
within the element declaration (XSC:ElementDecl element) for the element to
which the attribute belongs. If the XSC:AttDef element appears nested inside
an XSC:ElementDecl element, the Element attribute must be ignored. If the
XSC:AttDef element appears nested under the XSC:XSchema element, the Element
attribute should contain a name token corresponding to the Name attribute of
the element to which this attribute applies.
The Name attribute of the XSC:AttDef element provides the name by which the
attribute will be identified. A nested declaration is shown below.
<XSC:AttDef Name="status" ...additionalAttributeInformation.../>
This declares an element with the name Species that has an attribute named
status. If the status attribute was declared outside of the Species element
declaration, the declarations would appear as shown below.
<XSC:AttDef Name="status" Element="Species"
Merely naming an attribute may be adequate. Attribute declarations may
identify data types and provide information about whether the attribute is
required. By default, attributes will be assumed to contain character data
(CData), not be required, and have no default value. This information is
declared using additional attributes. The simplest attribute declaration
possible identifies an attribute as containing character data (CData) and
allows the attribute to be optional, as shown below.
Applications may also use the id attribute to provide unique identifiers for
attribute declarations using values that are unique within the XSchema.
2.4.2 Attribute Types
XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types.
All of them are declared using attribute values within the XSC:AttDef element.
The CData attribute type is one of the most common, permitting an attribute to
contain character data as defined by the XML 1.0 specification. If the Species
element were to contain an attribute providing the Latin name of the species,
the declaration could look like the following. (The Type attribute could
actually be omitted in this case, as CData is the default type.)
<XSC:AttDef name="Latin" Type="CData"/>
This attribute would then be available for use in instances of the Species
<Species Latin="Passerina cyanea">...additionalContent...</Species>
The ID attribute type is used to uniquely identify elements in a document for
application processing. IDRef and IDRefs attribute types are used to refer to
a single ID value in the same document or multiple ID values in the same
document, separated by whitespace, respectively. These attribute declarations
should be used with the same constraints as apply to ID, IDREF, and IDREFS
attribute types in XML 1.0.
The Entity and Entities attribute types identify the names of unparsed
entities. The use of these attribute types should be made with the same
constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. If
a document is checked directly against an XSchema without a conversion to a
DTD, information regarding unparsed entities must be available from the parser
for these attribute types to be meaningful.
The Nmtoken and Nmtokens attribute types are used to declare attributes that
must contain information conforming to the Nmtoken and Nmtokens productions in
The Notation and Enumerated attribute types are more complex, requiring an
Enumeration attribute to identify their possible content. These two
declarations use similar syntax, but the allowed values of Notation
declarations must match the Notations declared elsewhere in the XSchema
If the status attribute of the Species element were to allow the values of
extinct, endangered, protected, and non-threatened, an appropriate enumerated
type declaration would look like:
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct
endangered protected non-threatened"/>
A Species element created conforming to this declaration might look like:
2.4.3 Attribute Defaults
XSchema requires attribute declarations to provide information about the
default value of a given attribute. XSchema provides for the four cases
supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue,
though they are expressed as choices between required and not required and
fixed or not fixed, with an optional default value. There may be only one
default value declaration per attribute.
Required attributes (identified in XML 1.0 by #REQUIRED) are identified by
assigning the value "Yes" to the Required attribute of an XSC:AttDef element.
For instance, if the Latin attribute described above was required by the
Species element, the XSC:AttDef element would contain a Required attribute:
<XSC:AttDef name="Latin" Required="Yes"/>
Optional attributes (identified in XML 1.0 by #IMPLIED) are identified
assigning the value "No" to the Required attribute of an XSC:AttDef element
and not assigning a value to the AttValue attribute. Implied indicates that
there is no default value provided, and also that no value is required. If the
Latin attribute is optional, the XSC:AttDef element would contain an
XSC:Implied element: (Note that this is the default status and the Required
declaration does not need to be made explicitly.)
<XSC:AttDef name="Latin" Required="No"/>
Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified
through the use of the Fixed attribute and the AttValue attribute, which
contains the fixed value for the attribute. Attributes declared using fixed
value cannot declare a different value for that attribute. Fixed effectively
hard codes attribute values into particular elements. If the Species element
had a planet attribute, a Fixed attribute given the value of "Yes" would
identify the fixed nature of the attribute and the AttValue attribute would
provide the value.
<XSC:AttDef Name="planet" Fixed="Yes" AttValue="Earth"/>
Attributes may also be provided with a default value that may be overridden by
other declarations. These default values are identified through the use of the
AttValue attribute. The status attribute of species elements described above
would be an appropriate target for such a default value, especially if most
species being described fell into a particular category:
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct
endangered protected non-threatened" AttValue="non-threatened"/>
Any type of default (required, fixed, etc.) may be used with any attribute
type, though default values should always correspond to acceptable values for
the attribute type.
This notation also permits the declaration of certain attributes (IDs with
defaults, for instance) that are prohibited by the standard XML 1.0 DTD
syntax. Developers who use these combinations should be certain that their
documents will work in DTD-only environments as well as XSchema environments.
An XSchema processor that produced normalized-for-DTD use documents could
expand these default values and include them in document instances for use
with DTD-only environments.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)