[
Lists Home |
Date Index |
Thread Index
]
[Jeffrey Fitzgerald]
> Obviously a question from an XML newbie...
>
> But what is the point of custom naming xml elements when they are not
> accessed in an OOP manner?
A good question, and there are good answers.
> ...
> My understanding is that you don't access the contents using syntax like:
> newbie.question.whatsUp.value, but rather an obscure
> childNodes[0].childNodes[0].childNodes[0].nodeValue (not even sure if that
> is right). But in any case, if you don't use the custom names
> then why not do:
>
> <blah>
> <blah>
> <blah>...
>
First of all, computer do not care what they names are as long as they are
different where they need to be different. But humans do. Markup data is
not just for computers. Of course, _some_ markup data is intended to be
just for computers, but not all. Even when a data format is intended to be
for computers, having a human-readable format is a huge advantage for the
application developer, not to mention the format designer.
Thus, when the actual format is not human-readable, as for asn.1 or machine
code, there is generally some human-readable version (like assembler) so
that code can be constructed. XML just stays as is and does not get
translated. In this way no specialized tools are needed to work with it.
As an example of the value of human readability, consider this fragment of
HTML -
<p>This is a <strong>tiny</strong> example of the work reported in <a
href='http://www.example.com/review/24a'>[Jones2002]</a>.</p>
Think how much harder it would be to write and maintain this fragment if it
read this way -
<blah-1>This is a <blah-2>tiny</blah-2> example of the work reported in
<blah-3
blah-4='http://www.example.com/review/24a'>[Jones2002]</blah-3>.</blah-1>
Second, xml is not OOP, and there is no single object model that fits a
given xml data set. So names are needed that are relatively independent of
a possible OO implementation. Of course, you could make a given
implementation more "efficient" by tuning the xml for it, and there is
nothing wrong with that. But usually, data ends up getting put to uses you
did not expect at the start, and the more tightly the data is coupled to one
implementation, the harder it is to adapt to other uses. A trade-off to be
sure, but maintenance and normal evolution of a system have to be included
in the loose-vs-tight coupling tradeoff.
Third, even sticking within a pure programming viewpoint, not all
programming is OO-style. There is plenty of C and Haskell, for example. So
slanting too much towards an OO approach again reduces flexibility.
Fourth, there are in fact systems that let you access xml data similar to
your proposal. One of them is xpath/xslt (e.g., xsl:value-of
select='/newbie/question/whatsup'/>). You really can have your cake and eat
it too, in this regard at least, if that is what you want.
For OO systems, the usual cost of having such capability is that you need to
have a schema available (so that the object types can be automatically
created), whereas some other types processing can do fine without one.
Another tradeoff.
To sum up, markup, including xml, offers advantages in the area of human
readability, use coupling, flexibility, ability to be created with simple
tools, and good potential for evolution. The tradeoffs tend to be in the
areas of "efficiency" - such as size for the data set, specialized access
techniques, and speed of processing. The rapid spread of xml could be taken
as a sign that xml has gotten the tradeoffs right better than anything else
so far, but even if that turns out to be true, it does not mean that xml is
the best answer to every problem.
Thanks for asking!
Cheers,
Tom P
|
