Do you want the parsed xml displayed?
And if so, how are you wanting it to be
displayed.
I'm not familiar with seeing xml DOM's
showing parsed output xml unless it's
called with xml functions or through a
viewer/editor.
The functions chosen for %quickparse.r
are the ECMAscript binding functions, wich
I find a lot easier for use with webpages
and with inline javascript function calls in my
View browser,
ie...
<p id="p1"color="red">Change this text</p>
<input type="button"
onclick="getattribute(p1).setnodevalue({This text changed})" />
....The changes are made in the html
paged and VID code wich can be saved .
and in rebol...
<input type="button"
onclick="p1/text.{This text changed}.show.p1" />
....But the html is not changed and if the
paged is saved the original code remains.
There's no need to use parse-xml with
these functions because you can drill down
into any part of the xml/html file to make
changes and use them with Rebol code.
But in the spirit of Rebol,
"To each his/her own"
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 10, 2004 5:19 AM
Subject: [REBOL] Re: object2XML
> >
> > What do you wish to do with namespaces?
> They aren't at all as
> > straightforward as they seem. They get
> inherited, and the namespace
> > prefixes can be reused within the nesting
> of the document all the while
> > resolving to totally different namespace
> >URIs.
> I believe this is what Joe English called
> psychotic namespacing.
>
> i've seen a lot of fucked up xml in my time,
> it's actually quite rare to see:
>
> <tag xmlns="http://tag.com";
> xmlns:t="http://tag.com";>
> <t:tag>
> <p>hi</p>
> <t:tag xmlns:t="http://nottag.com";>
> <t:p>hi</t:p>
> </t:tag>
> </t:tag>
> </tag>
>
> but it is of course possible, my perspective
> is to penalize that kind of structure, to
> optimize for more common structures and hell
> if it turns out in the middle of analyzing a
> structure that it is this kind of mess, to
> restart, so it takes longer, too bad.
>
> Also from a namespace point of view the
> prefix is absolutely meaningless, so one
> could in fact process the above with a
> namespace function that if it encountered a
> prefix the same as one it has encountered
> before but bound to a different namespace
> then all it has to do is to autogenerate a
> prefix, change the value in the block to
> that prefix, and move on.
>
> > The namespace processing,
> > if it has a chance, should be put into the
> parser itself and not in
> > xml-to-object or in some higher level
> processing. Adding in a namespace
> > aware SAX2-style handler into parse-xml is
> IMHO the only workable way to
> > go.
> Well I don't agree. for reasons given in
> other post and this one.
>
>
>
> --
> To unsubscribe from this list, just send an email to
> [EMAIL PROTECTED] with unsubscribe as the subject.
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
