World: r3wp

also, although I have not looked at rebelxml in this regard, rebxml 
handles many of the xml idiosyncracies in the XML specification like 
empty tags, CDATA blocks, and some level of character conversion 
to handle unicode and & escaped chars.

Great to see my work is being used! :-)

How does rebxml compare to gavin withead xml-parser.r ?

its easy to use? and will get your job done within minutes of trying. 
  ;-)

I used Gavin's code in the past and found very complete and useful, 
specially when using xml-object.r

it seems powerfull, but I had a hard type getting it to work.  I 
WAS pressed for time though.

speaking of XPath (Reichart's msg on Altme group), I wonder if there's 
need for it in the community?

1) people want XSLT and XPath in rebol, because it's the standard 
and so on.

2) people want a dialect that offerst XSLT/XPath-like functionality 
to work on REBOL trees (as opposed to XML)

3) noone cares about representing data as trees in REBOL because 
dialects are much better anyway

(pick your choice :)

why not post this on REBOLTalk.com forum as a poll?

have AltMe, ML user participate in this poll

i'm just trying to get some ideas. not a real poll. but maybe we 
can post this on reboltalk too.

I'd lead towards 3.

But that's because I heft XML into REBOL objects and fiddle with 
it from there.

That gets away from the strict hierachy of XML, so I don't need to 
think about basically insane things like XSLT's axis processing

and we already have data as trees in rebol, nested blocks and objects... 
so I don't think its going to help much.

although getting XML:schema LOAD/SAVE , complete, native  XML 1.0 
LOAD/SAVE  that would at least allow us to start using XML in the 
first place  ;-)

so my vote  3)

we already have data as trees

 - if you use that, then tree rewriting would be very useful for you, 
 wouldn't it?

can you further define "tree rewriting"

does having XSLT also means we can map that into /View?

well, if you can write a stylesheet that outputs a layout.  Not at 
all impossible, <xsl:output method="text" />

max: tree rewriting is the technique that compilers use to get from 
the source AST to the final machine code; you can also imagine purely 
functional languages as special tree rewriting engines.

basically, you have a tree, and you have a set of rules for rewriting; 
a rule is a pattern and a replacement for the matched node

Tree rewriting is a model of computation which is used in a variety 
of contexts within computer science, for example in semantic specification 
and compiler implementation

ok, so you pre-specify how path /aaa/bbb/ccc/ specifies data in another 
tree  /xxx/yyy/zzz ?

no, you specify a pattern that can match a subtree, and replace that 
subtree with something else.

xslt does something very similar; it matches a number of nodes (via 
xpath), then creates a new tree based on those nodes. rules are applied 
recursively so that you end up with a new tree starting from the 
initial tree.

there are only two votes so far, howeverr both voted for 3. maybe, 
we could introduce a new concept to CS, "dialect rewriting". :) it's 
the same as tree rewriting but without a tree. ;)

dialect rewriting is basically what my rewriting engine for rebcode 
does; it's rewriting where instead of using a regexp you use a parse 
rule; and instead of compiling a tree to another tree you compile 
a dialect to another dialect.

so it can be considered a superset of tree rewriting (since you can 
think of a dialect to represent trees)

i don't know if this concept can be generalized easily. but it would 
be interesting to figure out.

But by avoiding the AST aren't you throwing the possibility for optimizations, 
a direct rewrite engine is more like a literal translator. The cool 
think of having an AST is all the tricks that you can play to produce 
more efficient code at the cost of pre-processing time.

Hmmm.....

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).