RFC: Attributes and XML-RPC

[Tyler Baker]

Erik James Freed wrote:

> My thinking is that it is considered harmful to have two ways of doing
> such semantically equivalent things, because this can easily lead to more
> complicated implementations
> and more complicated interfaces than is optimal. This rule of course can be
> immediately broken if there is some truly useful distinction between the two
> (they are not truely equivalent). The case
> Tim is making for breaking this rule is one of readability e.g. that
> attributes are more readable for certain features. Presumably this
> readability advantage would diminish and reverse where attributes are long
> enough to really want to be on multiple lines. So you have a feature where
> the lenght of the string representing the value determines an implementation
> change (kind of fugly as data modeling goes). I can see either side, but I
> think that
> readability is a troublingly subjective metric. Another argument is that
> this seemingly small semantic aliasing may cause more problems in the future
> as new features are added. Note the effect on query languages for instance.
> God knows they need all the help they can get to limit complexity.
>
> I would conclude that attributes were a truly unfortunate decision, and we
> will live to regret it more in the future, but does the impact of this
> decision have enough of an force to reverse a long standing language
> feature? I kind of doubt it, I bet that there is now enough cultural
> momentum to prevent that.

Personally I think it is bad practice to contain data that an application uses directly like a
price, or a coordinate even though it is probably more intuitive to read:

<Rectangle x="0" y="0" width = "0" height="0"/>

than

<Rectangle>
  <x>0</x>
  <y>0</y>
  <width>0</width>
  <height>0</height>
</Rectangle>

A rectangle will never really change and you cannot really extend a rectangle. But attributes
are very useful for describing the context with which the element should be treated, for
example namespaces. Namespaces nodes as they are called in XSLT are not really relevant to the
application itself but delimit the scope of a "namespace" and
define what the namespace prefix actually means. Really, I would of prefered to delimit
namespace scopes using PI's as in the long run I think would of been much more extensible and
not so obtrusive, but that is a debate that has been rehashed over and over again and with no
success. But it would be nice if namespaces were defined by PI's so that only the XML parser
needs to deal with the PI's when constructing a QName and let the application do whatever it
wanted with attributes to describe the context of an element AS IT APPLIES TO THE APPLICATION
PROCESSING IT, if anything.

If you are going to actually use "Namespaces in XML" you are probably better off not using
attributes at all so that if someone actually looked at your element tree, they could choose
to ignore attribute processing altogether instead of having to check each attribute to see if
it is a namespace node before presenting it to the application.

I myself would rather use a namespaces solution that works (even if non-standard and home
brewed) than something which is totally broken in concept as well as implementation.

Tyler


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/ and on CD-ROM/ISBN 981-02-3594-1
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)