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

RE: Groves, IsNess and the Generic Data Object. [was.. Another try on Gr

• From: Mark Birbeck <Mark.Birbeck@i...>
• To: xml-dev@i...
• Date: Mon, 20 Sep 1999 12:24:07 +0100

I feel a bit sorry for the grove guys, because as is usual in our
nerd-world, we never have discussions that go:

A: Hey, how about this?
B. Wow, great idea but 'fraid it will have to wait.
A: That's no problem. Nice talking to you.

We always have:

A: Hey, you must do this or your edifice will collapse.
B: No, who needs it, it's only for geeks.
A: You're only saying that because you are:
	(a) a member of the establishment
	(b) funded by Microsoft
B: You're only saying that because you are:
	(a) a member of the establishment
	(b) funded by Microsoft
A: Why doesn't anyone listen to me?
B: Pardon?

And so on.

It seems pretty straightforward to me that if you can accept a paradigm
that abstracts collections of data into nodes, then you can accept an
abstraction that allows those nodes to be manipulated in a manner that
is closer to the structure of the original data. In other words, if you
can accept that the transformation of:

<author>
	<name>Fred</name>
	<dob>25/12/0000</dob>
</author>

into:

	sName = doc.children.item(1).children.item(1)

is useful - because you can begin to generalise solutions, hide the
parsing, and so on - then why not accept that:

	sName = doc.author(1).name

is even more useful? And what about?:

	iAge = doc.author(1).age()

If you were writing a serious bullet-proof application you would
probably put a layer over the DOM which allows you to manipulate
'author' objects in this way anyway. You'd create some Java or C++
classes that sit on top of the DOM, and have to invoke the right one
depending on the element type of the node you were currently
manipulating. As far as I can tell from a quick reading, all the grove
fans are saying is that just as you give everyone a parser and node
walker in the API, now let's give them access to the objects, 'as
objects' and not as nodes. This extra layer of code would then become
much simpler.

Now, I don't think this should hold up the onward march of XML; there is
no way that everyone is ready for this 'paradigm shift' anyway. But
whether we are ready or not shouldn't prevent us from having a useful
discussion. People are being a bit lazy by dismissing the approach with
"I'm quite happy walking the DOM" and "It's not that difficult to use
the XML API".

It doesn't seem that radical (or scary) to me, to say that at some point
in the future an approach like groves will be an extremely common way of
manipulating data. But I also don't think I'll lose my shirt if I bet
that for now though, the initial advances made by XML and nodes will be
more than enough to keep us going.

Best regards,

Mark

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: RE: Groves, IsNess and the Generic Data Object. [was.. Another try on Groves]
• Next by Date: Re: Another look at namespaces
• Previous by thread: Re: Groves, IsNess and the Generic Data Object.
• Next by thread: Expat - basic help
• Index(es):
  • Date
  • Thread