[relax-ng] Approaches for defining common attributes

[MURATA Makoto <EB2M-MRT@asahi-net.or.jp>]

There is more than one approach for defining common attributes 
such as xml:lang and XLink attributes.  Here is my survey.

1. Existing approaches

1) Define common attributes in one schema module only once

xml:lang, xml:base, and xml:space are defined in one place, namely

	http://www.w3.org/2001/xml.xsd

and this schema is intended to be referenced by many schemas 
including XHTML schemas.

2) Define a complete schema for common attributes.

John Cowan used this approach in creating the RELAX NG schema for
XLink.

http://lists.xml.org/archives/xml-dev/200206/msg01074.html

This approach is similar to the first one in the sense that a
common attribute is defined only once.  However, rather than creating
a module, this approach creates a COMPLETE schema, against which many
documents can be validated.  Powerful name classes of RELAX NG 
makes this approach possible.

3) Define common attributes in many schemas repeatedly

James Clark used this approach in creating RELAX NG schemas for XHTML
(available http://www.thaiopensource.com/relaxng/xhtml/).  For
example, xml:lang is defined in

	http://www.thaiopensource.com/relaxng/xhtml/modules/attribs.rng

In other words, a common attribute is repeatedly defined by more than
one schema.

4) Extend ISO/IEC DSDL Part 4

DSDL Part 4 alows specific parts of an XML document to be extracted
and then validated.  Although the current draft allows extraction of
elements but does not allow that of attributes, we can extend Part 4 
and extract common attributes for validation.

http://www.y12.doe.gov/sgml/sc34/document/0363.htm

This approach is similar to the second approach.  Schema authors 
create COMPLETE schemas for common attributes and extracted 
attributes are validated against these schemas.

Moreover, this approach makes schema authoring easier, since it
becomes very easy to ignore uninteresting elements and attributes
(i.e., wild cards become unnecessary).


2. Discussion

1) Duplication and possible inconsistencies

If a common attribute has to be declared many times, we have redudancy
and possible inconsistencies among schemas.

The first approach, second, and fourth approach do not have this
problem.  But the third approach does.

2) Schema authoring and maitenance

A common attribute (e.g., xml:base) may be introduced to an existing
namespace or a namespace containing common attributes
(e.g.,xi:include) may be created.  Ideally, it should be
straightforward to take advantages of such new attributes or
namespaces.

The first approach requires that existing schemas import new schema
modules and that existing declarations in these schemas reference to
newly added common attributes.  The third approach requires that each
existing schema be (possibly significantly) modified.  The second and
fourth approach does not require any changes to existing schemas.

3) Expressiveness

Different schemas may require different constraints on values of
common attributes.  Moreover, one common attribute may become
optional or required in different locations of different schemas.
Ideally, it should be easy to express such variations of 
constraints.

The first approach does not work.  In fact, XHTML does not use
http://www.w3.org/2001/xml.xsd but rather uses a modified local copy.
The second and fourth approaches exhibit the same problem.  XBRL 
also creates a local copy.

On the other hand, the third approach has a big advantage: different
schemas can easily impose different constraints on attribute values.


Cheers,

Makoto <eb2m-mrt@asahi-net.or.jp>