What are data attributes (was Re: <XML:SCRIPT>)

[W. Eliot Kimber]

At 02:33 PM 7/9/98 -0400, John Cowan wrote:
>W. Eliot Kimber wrote:
>
>> This is what notations are for (unfortunately, by choosing not to include
>> data attributes, XML has severely limited the utility of the notation
>> feature, but I'm sure that will be corrected).
>
>What are data attributes?

In SGML, you can declare attributes for a notation and then use those
attributes as part of a data entity declaration or (using the "Data
attributes for elements" (DAFE) facility of the General Architecture [part
of the SGML Extended Facilities published in ISO/IEC 10744:1997
<http://www.ornl.gov/sgml/wg8/docs/n1920/>]) on elements governed by that
notation.  They are called "data attributes" because they are attributes of
data entities (or, more generally, data governed by a notation processor),
rather than attributes of elements.  They are often coloquially referred to
as "notation attributes", which isn't a bad name, it's just not the one the
SGML standard chose.

The idea is that the attributes act as parameters to the notation
processor, whether the processor is processing a data entity, element, or
attribute value.

A typical example would be an attribute that influences the interpretation
of a graphic, represented by a data entity:

<!-- NOTE: This is SGML, not XML -->
<!DOCTYPE MyDoc [
 <!NOTATION SomeGraphicFormat SYSTEM >
 <!ATTLIST #NOTATION SomeGraphicFormat 
    scale      -- Nominal scaling value for presenting the graphic --
      CDATA    -- Value is a percentage --
      "100%"   -- Default: not scaled --
 >

 <!ENTITY Graphic-one 
    SYSTEM "graphic1.pic"
    NDATA SomeGraphicFormat
    [ scale="50%" ]
 >
]>

In the HyTime architecture, through the DAFE mechanism, we use data
attributes as a way to associate attributes of elements with their
corresponding data attributes.  The SGML standard doesn't define a
mechanism by which element attributes and data attributes are correlated,
so we had to invent the DAFE facility to define the correlation mechanism
we needed for HyTime's purposes (feeling fairly certain that other
applications would find it useful, which is why it's part of the General
Architecture and not the HyTime architecture).  

The rule is very simple: if an element is governed by a notation (because
it exhibits a NOTATION attribute) AND that notation has attributes AND the
element exhibits attributes whose names match those of the notation's
attributes THEN the attributes are taken to be instances of the notation's
attributes. 

This means, for example, that when you pass an element to a notation
processor it can, with confidence, interpret any attributes it recognizes
as being those defined by the notation it implements.  Without this
facility, any name matches between element attributes and notation
attributes might be coincidental and you would have no way of
disambiguating name clashes as notation attributes and element attributes
are separate name spaces.

The facility also provides a name remapping facility that is just like the
architecture name remapping facility (which is just like the one defined by
Xlink).

HyTime uses notations to define types of queries that are then used with
elements (or attributes) that represent query instances (the "queryloc"
element form and location type in the HyTime architecture).  If you want to
define a query that can take arguments (say a canned query for a specific
purpose), you can use attributes to pass the arguments in a well-defined way.

First, I define a notation that represents my query.  A typical example
would be a query that finds all elements of a particular type:

<!DOCTYPE MyDoc [
<!-- Declare use of the HyTime architecture (e.g., associate the document
with the HyTime "name space" and semantics): -->
<?IS10744 arch
   name="HyTime"
   public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based
Structuring Language (HyTime)//EN"
   dtd-public-id="ISO/IEC 10744:1997//DTD AFDR Meta-DTD
Hypermedia/Time-based Structuring Language (HyTime)//EN"
   doc-elem-form="HyDoc"
   bridge-form="HyBrid"
   renamer-att="HyNames"
   options="queryloc dafe"
?>

<!NOTATION Elements-with-GI
   PUBLIC "Query that returns all elements with a given GI within location
source"
   -- Note: location source is always current document. --
>
<!ATTLIST #NOTATION Elements-with-GI
   gi       -- GI to query on --
     CDATA
     #REQUIRED  -- Gotta specify something --
>

<!ELEMENT Elements-with-GI-Queryloc
    - O
    EMPTY
>
<!ATTLIST Elements-with-GI-Queryloc
   id
     ID
     #REQUIRED
   gi       -- GI to query on --
     CDATA
     #REQUIRED  -- Gotta specify something --
   notation  -- Notation that governs interpretation of this element 
                as a query. Required by the HyTime architecture.  --
     NOTATION
     (Elements-with-GI) #FIXED "Elements-with-GI"
   HyTime    -- Define mapping of this element to HyTime-defined
                query location address element form. --
     NAME
     #FIXED "queryloc"
>

]>
<MyDoc>
  <Link linkend="all-sections-loc">See all the sections of this
document</Link>
  <Elements-with-GI-Queryloc id="all-sections-loc" gi="Section">
</MyDoc>

When a HyTime engine examines this document, it will perform the following
processing:

1. It will see that the Elements-with-GI-Queryloc is a HyTime queryloc
(because of the value of the HyTime attribute). 

2. It will expect to find an attribute called "notation" whose value is the
name of a notation declared in the same document. 

3. It gets the notation name (Elements-with-GI) and looks up the notation
declaration. 

4. It goes to its "notation processor" table to see if there is a processor
(DLL function, COM object, JavaBean, etc.) associated with the public ID
"Query that returns all elements with a given GI within location source". 

5. It finds a processor and passes it a pointer to the element object
(grove node, DOM node, whatever).  It expects to get back a node list (or
its equivalent) representing the results of the query. It waits for that
result.

Upon being called, the notation processor does the following:

1. Looks at the element to see if there is a GI attribute specified. It
knows to do this because it embodies the knowledge of the rules for the
notation, including the fact that it takes a GI attribute. It knows this
either because the programmer who created it knew it or because it examines
the notation declaration and sees that there's an attribute declared for it
as well.  It depends on how generalized the processor is.

2. Sees that there is a GI attribute and, because this system implements
the DAFE facility and because the document declares that it is using it
(options="queryloc dafe") knows that it can interpret the GI attribute as
its GI parameter.

3. It takes the value of the GI attribute ("Section"), performs its query,
and returns the result to the HyTime engine.

Upon being returned to (or called back), the HyTime engine takes the
resulting node list and does whatever it does with it. If the address was
used to define the members of a link anchor, as it is in this example, it
would use the node list to populate the "anchored objects" property of that
anchor, for example (using the terminology of HyTime's abstract data model
for representing link-related information).

The process I've described is no different from what people have been doing
for years in SGML and HTML and XML, it's just that we've slapped a little
layer of standardized syntax and semantics on it to enable wider
generalization.  It does, however, depend on the data attributes facility,
which the XML WG, over my strong personal objection (for what that's
worth), elected not to include in XML.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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)