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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: "Simon St.Laurent" <SimonStL@classic.msn.com>
  • To: "Xml-Dev (E-mail)" <xml-dev@ic.ac.uk>
  • 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 
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 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 
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 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: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 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.

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

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: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:

<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 an 
XSC:Implied element: (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 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: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:ElementDecl>

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: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