Attributes with Intent

[W. Eliot Kimber]

At 08:08 PM 5/4/98, Peter Murray-Rust wrote:

>For example it seems that a Node must have 2-3 sets of methods:
>	getAttributeValue(String attName);
>	getPseudoAttributeValue(String specialAttnameInContext)
>and 
>	getPseudoAttributeValueAfterRemapping(String possiblyRemappedAttributeName)

Pretty much.  I usually have these functions:

- AttValue(string LocalAttName)
  Returns value of attribute given name as specified for the element.
- LocalAttName(string ArchAttName) 
  Returns local name mapped to architectural name (e.g., whatever xml:lang
  has been mapped to for this element).
- ArchAttvalue(string ArchAttName)
  Returns the value of an attribute given its architectural name. Resolves
  remapping as necessary.
- AttEffectiveValue(string LocalAttName)
  Returns the effective value of an attribute given its local (to the
document)
  name. 
- ArchAttEffectiveValue(string ArchAttName)
  Returns the effective value of an attribute given its architectural
  name.

Obviously, the last two are implemented using the first three to recursively
examine the ancestry of the current element.

There's another case, less common, but to think about, which is the case
where the effective value of an ancestor element's attribute is dependent
on the value in its content. You see this most often with security
classification attributes, where the effective security classification of
an element is the highest classification of any of its content, e.g., in
this example, the document element's effective security "eyes-only":

<?XML version="1.0"?>
<!DOCTYPE doc [
 <!ATTLIST doc
    classification
       NAME
       #IMPLIED
 >
 <!-- Default: highest classification of descendants where
      uncl < top-secret < eyes-only
  -->
]>
<doc>
 <part classification="top-secret">...</part>
 <part classification="eyes-only">...</part>
</doc>

Where "eyes-only" is a higher classification than "top-secret".

I would not expect to see a generalized method for determining the
effective value of attributes in this way.

Propogation of attribute values down the hierarchy is also trickier than
just looking up the ancestry, because you might have rules about how
defaults get set or reset. HyTime's "default value list"  (clause A.5.6,
Default value list, part of the General Architecture), provides a more
complete facility for specifying exactly what the defaults for implied
attributes are and how they should be propogated.  It's an example of the
sorts of options you need to anticipate in the general case.

>The touchstone of XML-applications - the
>desperate Perl Hacker - is not necessarily going to build a stack of the
>attributes of an/every element.

How hard can it be?:

# NOTE: forgive my pseudo Perl syntax-- you know what I mean.
@attstack()   ; # stack of attlist structures
@attlist{name} = "value" ;# Associative array of atts values by name

sub process_element() {
   
   push(attstack, attlist); # Push associative array of atts on stack
   for each att in element.atts  ; # Method that returns array of att objects
	$attlist{att.name} = att.value
   next

}

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  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)