World: r3wp

If its more like a block of records, it would be DOM. parse<->sax, 
load <-> DOM.

Thats what i understand from the overviews. Then comes how it works, 
and i am quickly back to real parse and load..

There are two major types of XML (or SGML) APIs:

Tree-based APIs

    These map an XML document into an internal tree structure, then allow 
    an application to navigate that tree. The Document Object Model (DOM) 
    working group at the World-Wide Web Consortium (W3C) maintains a 
    recommended tree-based API for XML and HTML documents, and there 
    are many such APIs from other sources. 
Event-based APIs

    An event-based API, on the other hand, reports parsing events (such 
    as the start and end of elements) directly to the application through 
    callbacks, and does not usually build an internal tree. The application 
    implements handlers to deal with the different events, much like 
    handling events in a graphical user interface. SAX is the best known 
    example of such an API.

It should work -- XML -> DOM -> XML -- with the DOM being a document 
structure and a collection of methods for manipulating itself.

taken from: http://www.saxproject.org/event.html

If the internal representation is an object-base tree, what are the 
barriers to the 'get-elements-by-tag-name function?

Yes, load is our tree, parse our events. Think of parse as "Here 
comes the word 'file. Yuppa, and a real 'file! . Good, and a 'binary!. 
(fine, now i store that data in that file)"

http://www.zvon.org/xxl/DOM2reference/Output/index.html

what would you find more usefull when working with XML? DOM sounds 
good when working with loaded document, all those find-element-by-name 
etc funcs sound usefull. For streaming kind of purposes (protocols), 
SAX sounds being a better option ...

Yes, that what i understand too.

What are the SAX methods for manipulating an XML document, and how 
easy is it to save the changes?

Chris - following is true imo which favors SAX with me:


Tree-based APIs are useful for a wide range of applications, but 
they normally put a great strain on system resources, especially 
if the document is large. Furthermore, many applications need to 
build their own strongly typed data structures rather than using 
a generic tree corresponding to an XML document. It is inefficient 
to build a tree of parse nodes, only to map it onto a new data structure 
and then discard the original.

You've lost me...

The thing is - result of DOM parsing is tree representation of document 
- in Rebol .... the question is, what if you need data organised 
otherwise? You will have to search that tree and build such structure 
which fits you anyway ....

yes, saving the changes - will have to think about it. .... it might 
be tricky, if even possible :-)

Which is the point in my suggesting the DOM :o)

so we should have both :-)

or just kind of clever REBOL mixture :-)

I don't think the DOM should be as complex as you suggest.

noone said we have to develop 1:1 solution ... let's develop one 
which fits the need best ...

actually that description favors DOM. First, we dont want to save 
memory, we are scripters. We use load too.. Second, we are not strongly 
typed (they mean static typed). SO we can happily be generic.

Organizing data - if data is in blocks, you can use path-notation, 
but also runwith a parse-rule through the loaded data.

Chris < it appears not to work out the box...>

I'm using Gavin's script from REBOL.org unmodified in a real project.
It works for me.

But I may be encountering a different subset of XML possibilities 
to you.

It is a complete (as is my understanding) way to manipulate an XML 
document.  It is also a standard, familiar to anyone who has used 
Javascript.

ok, is anywhere complete and nice DOM specs? W3C org?

But we should not think that having DOM will allow us to manipulate 
website elements, as having document loaded into rebol DOM will not 
allow us to manipulate DOM tree loaded into browser :-)

But for that parse-rule we need a fixed mapping, i think i start 
with functions first, until i know what i need. Easier to change.

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-parse.r
>> parse-xml+ read http://www.ross-gill.com/
** Script Error: Invalid path value: parse-xml
** Where: parse-xml+
** Near: xml-parse/parser/parse-xml code

(that looks mangled in my AltME window)

If they are functions, we can map the same names to browser-calls. 
think protocols.

Petr -- look at my links above...

Petr, that is exactly what the DOM does -- and web site elements 
*are* xml.

Btw Chirs, thanks for the links.

Wait, I'm reading your sentence incorrectly.

No worries, again this seems straightforward -- http://www.zvon.org/xxl/DOM2reference/Output/index.html

Chris -- that do from REBOL.org works for me.

parse-xml is an RT mezzanine. Perhaps its not present in your rebol.exe

Petr, I don't anticipate being able to manipulate a browser's DOM.

Sunanda, it appears to be a problem in the script.

>> parse-xml read http://www.ross-gill.com

== [document none [["html" ["xmlns" "http://www.w3.org/1999/xhtml"
"xml:lang" "en" "lang" "en"] ["^/" ["head" n
one [["title" none [...

>> source parse-xml+
parse-xml+: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
    REBOL parse-xml function.
}
        code [string!] "XML code to parse"
    ]][
    xml-parse/parser/parse-xml code
]

Likely because in the code, it says -- parser: make object! [[  ... 
 parse-xml: ...]]

Similarly, the parse-xml+ arguments block is doubled too -- [[code 
[string!]]]

If I make those fixes, I get 'false' when I parse my homepage (which 
validates as xhtml)

Chris -- I don't get that problem,

But you did make me look closer, and my earlier statement was wrong.
I'm using

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-object.r
Which is similar to xml-parse, but not identical.
Example of usage:
probe: first reduce xml-to-object parse-xml
     {<?xml version="1.0" encoding="ISO-8859-1"?>
      <xxx>11</xxx>
     }

The simplicity of xml-to-object is nice, but for extraction.  Manipulation 
beyond changing text would be tricky.

True -- I'm only using it to load XML into a rebol structure for 
various reporting purposes. Not trying to round trip the data back 
to XMK after updating..

XMK!?  == XML

i im using the scripts made by Gavin the code is great, but libs 
for dom implementation are out there and are free i dont know why 
not to use this natively  in rebol i feel like the stone age here, 
tell me if im wrong but i feel like a cave man doing my parsing like 
this. if the code is free and the implementation is easy why not 
to have this in rebol ? just because we can exeed 650k ?

because it was not invented here :(

I think it's fair to say that Carl is not fond on XML:
http://www.rebol.net/article/0110.html
http://www.rebol.net/article/0108.html

(And, to be precise, neither am I....But there is a lot of it out 
there, and REBOL needs to work with it better)