From: Gavin Kistner <gavin@...>
Date: 2005-04-11T22:28:19+09:00
Subject: [OT] XML markup limitations [was Re: Free XML Databases (with Ruby!)?]

On Apr 11, 2005, at 7:01 AM, Jonas Hartmann wrote:
> Jonas Hartmann wrote:
>> I found a confusion mapping OO to XML, are the element names roles or 
>> types? That problem dissapears with RDF because you specify both 
>> roles and types, e.g. the confusion in XML:
>> <circle> <center x=0.4 y=0.5> </circle>
>> <document> <paragraph> </paragraph> </document>
>> There seems to be a confusion between roles and types. Circle is a 
>> type right? and center is a role?
> I am not familiar with "roles and types" in this regard - so I dont 
> know what you are talking about, but by your example I thought, do you 
> mean the distinction between datatypes/datacontainers and 
> data/dataelements?

I suspect so. It is a common problem, using subordinate XML elements to 
describe their parent, while at the same time using subordinate 
elements to describe a parent/child relationship:

<!-- Poor XML Design (IMO) -->
<Person>
    <Name>Don</Name>
    <Age>75</Age>
    <Person>
       <Name>Don's Son</Name
       <Age>32</Age>
    </Person>
</Person>

<!-- Better XML Design -->
<Person name="Don" age="75">
    <Person name="Don's Son" age="32 />
</Person>


So the general rule of thumb arises: "Use attributes to describe an 
object, and parent/child nodes to describe relationships between 
objects."

This guideline falls down, though, when you need to describe a complex 
attribute on the node. Often, the simple CDATA string format of an 
attribute is insufficient to describe an attribute well, so you end up 
with something like:

<FavoriteColor red="255" green="0" blue="102" alpha="152" />
or
<FavoriteColor rgba="255 0 102 152" />

The former is 'bad' because it is so verbose; the latter is 'bad' 
because it requires an external processor (or smart xslt agent) to do 
meaningful processing on the individual values. Further, the latter 
requires the processing agent to know the order of the values in the 
space-delimited string.

You can't even use the former solution in cases where an arbitrary 
number of points may exist, such as:

<Model vertex_locations="(10 20 30) (15 88 -12) (-17 89 10) (...) ..." 
/>

This is certainly preferable (IMO) to something like:
<Model>
    <VertexLocations>
       <Point x="10" y="20" z="30" />
       <Point x="15" y="88" z="-12" />
       <Point x="-17" y="89" z="10" />
       ...
    </VertexLocations>
</Model>
both in terms of verbosity as well as node encapsulation, but neither 
solution is good.

(Though these examples are contrived, the problem is not. For example, 
look at the information crammed into the 'd' attribute for an SVG Path 
element: http://www.xml.com/pub/a/2000/03/15/deviant/ )


We now return you to your regularly-scheduled Ruby discussion.

--
"When I am working on a problem I never think about beauty. I only 
think about how to solve the problem. But when I have finished, if the 
solution is not beautiful, I know it is wrong."
- R. Buckminster Fuller