Re: [xml-dev] Should attributes be prefixed

[David Megginson <david@megginson.com>]

Ronald Bourret writes:

 > Go with Evan's suggestion, then. Except in the case he mentions, I
 > have yet to see any advantage to an attribute being "in" a
 > namespace.

A specific use-case for Evan's example is RDF; consider the following
RDF document containing three objects belonging to the
http://foo.com/namespaces/genealogy/Person class:

 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
          xmlns:foo="http://foo.com/namespaces/genealogy/";>

  <foo:Person rdf:about="urn:xxx:001">
   <foo:name>John Jones</foo:name>
  </foo:Person>

  <foo:Person rdf:about="urn:xxx:002">
   <foo:name>Susan Smith</foo:name>
  </foo:Person>

  <foo:Person rdf:about="urn:xxx:003">
   <foo:name>Jane Jones-Smith</foo:name>
   <foo:parent rdf:resource="urn:xxx:001"/>
   <foo:parent rdf:resource="urn:xxx:002"/>
  </foo:Person>

 </rdf:RDF>

An RDF processor can read this document and build the appropriate
in-memory objects, properties, and relationships from it, even though
the only element in the RDF Namespace is the root element.

I suspect that prefixed attributes will be very common in XML-based
data interchange standards some day (assuming that there *are*
widely-used XML-based data interchange standards some day), because
they let you add new information to elements defined by other parties.

Another typical case is adding extended information to an existing
document type.  For example, ACME Inc. might want to add the initials
of the signing authority to every invoice.  If the industry-standard
"invoice" markup model doesn't have an "authority" attribute, but ACME
can define its own in its own Namespace:

  <inv:invoice date="20011122" acme:authority="dpm">
    ...
  </inv:invoice>

Presuming that the "invoice" model designers were bright enough to
write clear processing rules, including "ignore any unrecognized
attribute not in the invoice Namespace", then the extra attribute will
be guaranteed not to break anyone else's processing software.


All the best,


David

-- 
David Megginson
david@megginson.com