[www-dom] <none>

We should probably keep this on the public list, so others benefit from the
discussion.

> What do you mean by take an existing DOM as input?

There are XSLT processors -- such as Xalan/LotusXSL -- which can read their
input from an existing DOM tree, rather than insisting on reading it from
an XML source file.That's convenient if you already have the document's
contents loaded into a DOM.

>2) The dom app parses the xml file and builds a node list/tree to
>represent the xml file internally.

The DOM app generally calls an existing parser if it wants to do this.
Parsers are off-the-shelf components these days for many (but not all)
languages.

>But this is transparent to the user

Sorry -- it _isn't_ transparent. If you want to go from existing XML text
to an in-memory structured model of the document's contents, you need to
explicitly ask a parser to do the work.

>and how it's done is not in the spec.

True. An API for invoking a parser is expected to be added in DOM Level 3,
as part of the Load/Save chapter. Until that's ready, you have to use
whatever parser you have available and whatever API your parser supports,
or write your own.

> 4) The app somehow writes the node list/tree back to an xml file,
> but this isnt in the spec either.

True. An API for serializing a DOM's contents back into XML syntax is
expected to be added in DOM Level 3, as part of the Load/Save chapter.
Until that's ready, you have to use whatever serializer you have available
and whatever API your serializer supports, or write your own.

>Now I want an executable that does #2. But because my 4gl can't
>use foo foo :)) c++ routines I need to have the executable dump the
>node list/tree into a text file, which I can then load into my
>environment.

AH! I see! You don't have a DOM parser available that works with your 4GL.
So what you want is something that will parse the XML file, generate the
DOM, and output the DOM in a custom format which is easier for your 4GL to
parse into a DOM that you've implemented. That's a legitimate way of
avoiding the details of XML parsing, I suppose...

>1) I'll have to write the executable myself that uses the DOM api to
>parse and generate a node list/tree.
>2)This executable will then dump its internal node list/tree so my
>4gl can read it.

Slight correction: You'll have to write an executable that uses an parser
to parse the XML, and uses either DOM or SAX to drive the code which writes
out your node list/tree. (For a flow-through task of this sort, SAX might
be a better choice than DOM... and unlike DOM Level 2, the SAX APIs _do_
specify how one invokes a parser. You still have to obtain a suitable
parser, of course.)

Or: If the intermediate form is text-based, you might be able to  write an
XSLT stylesheet that performed this transformation. Converting an XML file
into another representation (XML or other) is what XSLT is all about.

>3) I then have to write 4gl code that manipulates the data and
>spews it out.
>4) the executable then has to read this text, generate a node
>list/tree from it and then use the api to create a new xml file.
>If the api supports that, that is.

As discussed above, the API doesn't; you'll have to find or write that
code.


>Demographic polls show that you have lost credibility across the
>board.  Especially with  those 14 year-old Valley girls.

That's OK, I never was very good at programming in VALGOL:
     Do i = 1 to oh I don't know like 100
          Do Wah=ditty*2
     Like fer sure
     Y'know?


______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 25 May 2000 14:22:59 UTC