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

Simon St.Laurent SimonStL at classic.msn.com
Sat Jul 18 17:12:19 BST 1998 

Here's the latest version of Attribute declarations.  The largest addition is 
section 2.4.3, which focuses on the new oddities of XSchema->DTD conversion 
brought on by the shift from child elements to attributes for declaring type 
and default value.

Equally important is the new language about the Element attribute of the 
AttDef element, built on suggestions from Ron Bourret and John Cowan.  I'm not 
sure if allowing these to apply to all elements is a good idea, or if they 
should simply be ignored.  If ignored is the choice, the last sentence of this 
paragraph will be easier to fix than going the other way:
---------------------------------------------------------
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 may contain a name token corresponding to the Name attribute of the 
element to which this attribute applies. If the Element attribute is missing, 
that XSC:AttDef declaration applies to all elements within the declaration's 
parent XSC:XSchema element and any child XSC:XSchema elements.
----------------------------------------------------------

As always, a prettier HTML version of this will be posted shortly at 
http://purl.oclc.org/NET/xschema. 

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies


2.4 Attribute Declarations

2.4.1 Overview

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 type of an attribute is defined with an attribute, as 
is a declaration of whether or not it is required and a possible default 
value.

<!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?)>
<!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>

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 may contain a name token corresponding to the Name attribute of the 
element to which this attribute applies. If the Element attribute is missing, 
that XSC:AttDef declaration applies to all elements within the declaration's 
parent XSC:XSchema element and any child XSC:XSchema elements. 

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:ElementDecl Name="Species">
    ...additionalElementInformation... 
    <XSC:AttDef Name="status" ...additionalAttributeInformation.../>
</XSC:ElementDecl>

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:ElementDecl Name="Species">
    ...additionalElementInformation... 
</XSC:ElementDecl>
...
<XSC:AttDef Name="status" Element="Species" 
...additionalAttributeInformation.../>

Merely naming an attribute may be adequate. Attribute declarations may 
identify 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.

<XSC:AttDef Name="sampleAttribute"/>

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:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef name="Latin" Type="CData"/>
</XSC:ElementDecl>

This attribute would then be available for use in instances of the Species 
element:

<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 
must 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 must 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 
XML 1.0.

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 
document.

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:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct endangered 
protected non-threatened"/>
</XSC:AttDef>
</XSC:ElementDecl>
A Species element created conforming to this declaration might look like:
<Species status="extinct">...additionalContentAboutDodos...</Species>

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 
with a value of "Yes":
<XSC:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef name="Latin" Required="Yes"/>
</XSC:ElementDecl>

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 a "No" value 
for the Required attribute. (Note that this is the default status and the 
Required declaration does not need to be made explicitly.)

<XSC:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef name="Latin" Required="No"/>
</XSC:ElementDecl>

Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified 
through the use of the Fixed attribute in combination with the AttValue 
attribute, which must contain 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 Fixed attribute has a value of "Yes", the AttValue attribute 
must be present.  A Fixed value without an AttValue must be treated as an 
error. 

For example, to declare a planet attribute for the Species element, 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:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef Name="planet" Fixed="Yes" AttValue="Earth"/>
</XSC:ElementDecl>

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:ElementDecl Name="Species">
...additionalElementInformation... 
<XSC:AttDef Name="status" Type="Enumerated" Enumeration="extinct endangered 
protected non-threatened" AttValue="non-threatened"/>
</XSC:AttDef>
</XSC:ElementDecl>

Any default (required, fixed, etc.) may be used with any attribute type, 
though default values should always correspond to acceptable values for the 
attribute type.

2.4.4 Combinations of Types, Defaults, and Default Values

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 test that their documents 
will behave as expected in DTD-only environments as well as XSchema 
environments. Additional processing of document instances may be necessary to 
produce normalized-for-DTD use documents if they included such attributes as 
default values.  The attribute type should always be considered more important 
than its default values in XSchema to DTD conversion.

The table below summarizes the possible combinations of XSchema attribute 
defaults and their XML 1.0 DTD equivalents.

Required	Fixed		AttValue		XML 1.0 Value
Yes		Yes		<value>		This does not occur in XML.  It 
							means that the instance file must 
							include the value and the value 
							must be the fixed value.  At best 
							this enforces duplication.

Yes		Yes		--			error - Fixed=Yes without a value 
							is clearly an error.

Yes		No		<value>		This does not occur in XML.  It 
							means that the instance file must 
							include a value and the default 
							happens to be whatever is given with 
							AttValue. This should be treated as 
							simply AttValue for maximum 
							compatibility.

Yes		No		--			#REQUIRED

No		Yes		<value>		#FIXED <value>

No		Yes		-- 			error - Fixed=Yes without a value 
							is clearly an error.

No		No		<value>		AttValue

No		No		--			#IMPLIED


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

More information about the Xml-dev mailing list