[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Abandon the (mistaken) belief that XML attributesprovide "

• From: Stephen D Green <stephengreenubl@gmail.com>
• To: "Costello, Roger L." <costello@mitre.org>
• Date: Sun, 20 Mar 2011 13:24:00 +0000

A very simple observation but in the example

 <altitude units="feet" value="12000">
      <!-- descendant elements -->
   </altitude>

the use of an attribute for metadata associated with the element
has the limitation that you cannot then have meta-(metadata) in
the same syntactic construct. If you wanted to add meta-metadata
to specify a codelist and provenance for the value 'feet' (such as
a units of measure codelist URL and the authority in charge of it)
using other attributes it wouldn't be so obvious that these other
attributes applied not so much to the 'altitude' element but to the
units attribute value.

Often attribute values have a codelist applied to them and this
might be (often is) hardwired into the specification of the vocab
of the XML but when there is the facility to late-bind the codelist
then it is better, I think, to use child elements so that 'grandchild'
elements can be added (and so on) for the meta-metadata that
will likely be required at some point. The element can always
have child elements added but you can't add attributes to
attributes (except as siblings which isn't so clear to interpret).

----
Stephen D Green



On 19 March 2011 14:54, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> I just did a search of the XML specification for the word "metadata"
>
> Number of occurrences: 0
>
>
> Consider this XML snippet:
>
>  <altitude units="feet">12000</altitude>
>
> I have heard it stated:
>
>   The units attribute provides data about the
>   element's data. That is, units provides
>   metadata.
>
> However, the XML specification makes no such claim about attributes providing "metadata". This is what the XML specification says:
>
>  Attributes are used to associate name-value pairs with elements.
>
> And then the specification goes on to describe the specific syntax for attributes.
>
> Thus, attributes don't provide data about an element's content. Attributes don't provide metadata.
>
> Attributes are purely a syntactic construct.
>
> If you abandon the belief that attributes provide metadata then it frees you to create XML designs based on the capabilities of the applications you use.
>
> Example: In XML Schema 1.1 attributes (but not elements) can be declared "inheritable". There are benefits to having an inheritable item. Namely, descendent elements can make decisions (using the new <assert> element) on inherited attributes. Thus, if it is important to enable the descendants of <altitude> to make decisions based on units and value, then design the XML using exclusively attributes:
>
>   <altitude units="feet" value="12000">
>      <!-- descendant elements -->
>   </altitude>
>
> In the XML Schema the attributes are declared inheritable:
>
>   <attribute name="units" inheritable="true" />
>   <attribute name="value" inheritable="true" />
>
> Note that your decision to make them attributes was not based on whether their values are providing metadata (whatever that means), but rather, based on the ability to exploit inheritance in XML Schema 1.1.
>
> Comments?
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

• References:
  • Abandon the (mistaken) belief that XML attributes provide"metadata" and set yourself free to explore capability-based designs
    • From: "Costello, Roger L." <costello@mitre.org>