World: r3wp

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)

I still believe it can the DOM be implemented succinctly in Rebol, 
in a way that not only makes it easy for Rebollers to manipulate 
XML content, but makes Rebol a desireable tool to work with XML, 
period.

XML is not a silver bullet rebol block are much powerfull than XML, 
thats if you'r dealing REBOL's only deployment, but when ic comes 
to manage interoperability things get a bit messy and confused.

I am with Chris here. XML may not be silver bullet, but you can do 
nothing if the other party decides to use and communicate using XML 
- you either can handle, or you can't - simple as that. You can argue 
with them about rebol and its blocks, they will not care :-)

XML as an interchange format is common, as Pekr says.....It many 
ways it is better than CVS files that we used to use.

But XML as a sort of toy in-memory database that can be updated with 
APIs like DOM -- well that is a lurch into a strange direction, and 
not one I'd he happy to take.

I'd never say XML was a silver bullet -- I wouldn't use Rebol if 
I did -- but it is a pain not to be able to do simple manipulation, 
especially when there is a standard method laid out for doing so.

Sunanda-  noone here talks about XML in-memory databases. XML databases 
are most of the time dirty tricks, as well as object ones ...

the thing is simple - you are ither able to read, change, store XML 
files, or not, simple as that .... so what Chris means is - being 
able to read XML into DOM like structure, then do something with 
particular fields, store it back into XML ...

I've thought a little about how to implement this, I see four main 
considerations -- parsing, internal representation, accessors, rendering. 
 1) can reuse RT's or Gavin's code, 2) objects? nested blocks?  how 
should this look?  3) functions tied to the objects in (2), or a 
dialect?  4) appears to be the easy part...

2) and to a lesser extent 3) are key to progressing.

I don't think it is a priority that 2) be moldable as we can take 
advantage of Rebol's 'quirks'.