World: r3wp

maybe noone votes for 3 because a) we have little understanding what 
xpath can do for us b) once we say "dialect" or rebol in general, 
we sometimess think it is cure for all proglems

the lack of vote for xpath and xslt..


maybe its because there is this thought of adding yet another layer 
just to manipulate the data etc (remember Carl's slide in DevCon 
2004 ?... with REBOL on one side against a stack of others on the 
other side)

maybe, but maybe not. We need to be able to interface XML (DOM) anyway 
.... (e.g. for plug-in )

BTW, Gabriele you have my vote on tree rewriting.

Actually I don't care what directly is available (as a user), if 
just some things can be done:

e.g. people need to process XML - thus people already knowing XSLT 
and XPATH would like to leverage their knowledge (I asume) - so if 
we get a dialect for this (2.) this is nice, but even nicer if there 
is some mechanism (a generalization) which allows to import an XSLT 
(ast?) or some XPATH query and return the (more rebolesque) according 
Rebol dialect

3. three has always this kind of attitude of being able to do everything 
better in Rebol itself - even if true (?), that's one of the problems 
with Rebol, that outsiders can't afford the time to do many things 
better (themself) or don't care, because they want use some standards 
nevertheless and Rebol drops out as an option


so I vote for 2. with the ability for 1. maybe by the possibilities 
tree rewriting (or dialect rewriting) offers (I have not much glue 
about this - so some of the experts should know)

I agree to MichaelB .... but maybe then I vote for 1, 2 and 3 as 
well, so that 3 can be translated to "standard"

I think Gabriel proposal is to rewrite the XML into an RXML "A easy 
to manipulate representation of XML in rebol". Then you rewrite back 
to XML if you need to.

that sounds good ... so far my only experience with XML in rebol 
is Gawain's work - better than nothing .... but what exactly do you 
mean by XML here?

this group exists for a long time, and IIRC initially we were more 
or less discussing rebol - XML interoperability - SAX or DOM parser 
in rebol .... while from what is being discussed now, sounds like 
slightly bit different topic?

Jaime: that's what I meant too. But the discussion jumps around quite 
a bit and as some of these terms are unfamilar (besides the simple 
I know what you're talking about) - it's hard to know what to vote 
for :-).

I guess people have _very_ differing needs in this. Some _really_ 
 need to handle XML with all strings attached to it, and others just 
want to interface to existing technoglogies and read / write xml.

I'd put myself in the second category, if ever I have to work with 
XML again, that is. And I surely hope this won't happen ;-)

I once used XML as a file format, just to play around with it. And 
later I found out, that I'd broken so many rules, that no other gram 
was able to read it anyways. ;-)

it turns out that i can do tree rewriting as a subset of dialect 
rewriting. it's a bit tricky but works well.

and, it's a few lines of code (half a page or so)

on top of this, one could probably implement something similar to 
xslt, to translate a tree (parsed from xml) to another tree (maybe 
xhtml or another xml doc)

now, it remains to consider something like xpath for selection

basically, what sql's select is for relational data, xpath is for 
xml data.

can we think of a generic way to select data represented with a dialect?

I have often missed structural pattern matching in REBOL, something 
like the match statement in Nemerle (I'm sure it's in other functional 
languages but that's the first that came to mind). You could combine 
a structural pattern specification dialect (like XPath) with a structure 
building dialect (like XSLT), and then make the dialect compilable 
to REBOL code that can be used over and over again. It would be like 
a regex compiler for structures - I would use this every day.


All you would have to do to implement actual XPath syntax would be 
to specify a standard mapping of XML semantics in REBOL data structures 
(see my block model in this group from last October) and then have 
compile the XPath syntax (in a string) to the structure matching 
dialect. Then you could work from there.


(Gabriele, sorry if this seems redundant - I'm trying to explain 
tree rewriting in more REBOL-like terms).

can we think of a generic way to select data represented with a dialect?


Do you mean "selecting dialected data" or "a dialect to select data 
that's in format X"?

selecting dialected data

i.e., if we think that dialects are better than trees for data.

when i think about representing data conceptually, i tend to always 
come up with a graph or a tree (then i map the conceptual graph to 
a relational model, or maybe to a dialect). so for selecting data 
a "navigation" approach (which is basically what xpath does) seems 
rather natural for me; then you can map the navigation to SELECT 
statements etc if needed.

so maybe my question is: is graph navigation (or, if you think it 
is general enough, tree navigation) a general enough selection model, 
or do you think that it would be missing something?

(maybe there just isn't any general solution to the problem of selection.)

brian: do you think that structural pattern matching could be done 
with parse rules too? or, do you think we need something like "longest 
match" (which can be implemented in parse but is tedious to do manually)

You can do some structural pattern matching with parse rules, but 
with how parse is currently implemented it can be a little awkward. 
The lack of arguments to parse rules make recursion quite difficult, 
and the lack of local variables make the rules difficult to use concurrently. 
It is difficult to examine both the data type and the value of elements 
in block parsing, to switch to string parsing mode for string elements, 
to parse lists, hashes or parens, to direct the parse flow based 
on semantic criteria (which is needed to work around any of these 
other problems).


And don't even get me started on the difficulties of structure rebuilding. 
The thing that is the most difficult to do in parse is the easiest 
thing to do with regexes: Search and replace. Didn't we make a web 
site years ago collecting suggestions for improving parse? Wasn't 
a replace operation one of those suggestions? What happened with 
that?


Structural pattern matching and rebuilding currently has to be done 
with a mix of parse and REBOL code that is tricky to write and debug. 
If parse doesn't get improved, I'd rather use a nice declarative 
dialect, preferably with before and after structures, and have the 
dialect processor generate the parse and REBOL code for me. If that 
dialect is powerful enough to be written in itself then we'll really 
be cooking.

Brian, did you post a rambo on parse after a discussion we have a 
while ago ?

Yup. I've posted on rambo about everything I've suggested and more. 
I hope they consider these suggestions for REBOL 3.

my rewrite function works quite well for search and replace. it still 
has the limitations of parse, though, but they don't seem a huge 
problem so far.

example: assume the AST for 3*1+2+0 is [plus [plus [mult [lit 3] 
[lit 1]] [lit 2]] [lit 0]]

we want to compile it to a forth-like processor

>> rewrite [
[        plus [plus [mult [lit 3] [lit 1]] [lit 2]] [lit 0]
[    ] [
[        ['lit set x number!] [push (x)]
[        ['plus into ['lit 1 1 0] set x block!] [(x)]
[        ['plus set x block! into ['lit 1 1 0]] [(x)]
[        ['mult into ['lit 1 1 1] set x block!] [(x)]
[        ['mult set x block! into ['lit 1 1 1]] [(x)]
[        ['plus set x block! set y block!] [(x) (y) add]
[        ['mult set x block! set y block!] [(x) (y) mul]
[    ]
== [push 3 push 2 add
]

(rewrite is currently 25 lines of code)

do you have common examples that you consider problematic for parse? 
we can probably use rewrite on the parse rules themselves to extend 
them in a similar way that compile-rules does.

That's pretty cool. But, isn't the output of the rewrite above missing 
the multiply ?

Oh, I see, it has optimized the expression.

Well, I'm back after a long time off the air... Now back online and 
talking from a brand new iMac, and I enjoy it :-)

I submitted RebelXML to rebol.org quite some time from now. I can 
see it as been examined by some people. Well, it should be great 
if I could get some feedback about it.

We'll use it in production very soon. I took a SAX approach because 
we've to manipulate big XML files, and it was a mean to boost performences.

why rebel and not rebol?

Is REBOL not pronounce REBEL ? It was just for the fun...

implementing schema is sooo much fun!

I wonder if REBOL can get standards fully compliant XML parser/emitter 
....

(I hope my previous post was read as intended... ironically!)    
;-)  although schema is pretty well defined and actually not too 
badly designed, its just so huge.

Well, no reaction to RebelXML. Do I have to assume it has no bugs 
or nobody is using it ? :-))

Folks seem to be using/talking about it ... just do a google search 
on "RebelXML". ;)

Well, Ashley, this is very kind of you :-) But after checking the 
links, it seems Google isn't my friend anymore :-))

Seriously, I need this lib for my work. Is there anybody out there 
who has ANY comment about it ? Please ...

Well, I just had a quick look. It seems to be clean code, well organised. 
Perhaps I can find some time to test it out myself in a few days.