AltME groups: search

Yes, I'm aware of that REBOL trick. :-) It's because, what I'm parsing 
might be blocks within blocks in a recursive way.

XML is an example of such a structure. If I see a start-tag, I insert 
the beginning of a block in my result, then parse further in the 
document finding content and other start-tags and so on. The best 
way is to produce the output in a seriel manner from beginning to 
end, like I parse the input.

Sunanda, Can it be a manually maintained xml file until it can be 
automated?  I am doing that for my internal blog until I add the 
automation code to blog. r (that I expect Carl already has on his 
version).  I have a trigger for when a blog article is added to use 
"editor ftp://...../rss.xml"to make whatever additions that I want 
to expose via RSS.  It's suboptimal but I don't have any complaints 
from the people that they have to visit the pages to see What's New. 
 And since they weren't visiting regularly to poll for What's New 
anyway, if the RSS feed it updated a few hours later it is still 
an improvement.

what about alread mentioned open office format? Well, I expect it 
being rather complicated XML, but who knows ...

One of the goals with the MakeDoc format is, that it's possible to 
easily read with a normal text window, and some people may want to 
edit it with a normal text editor and write the formatting chars 
themselves. XML is not suited for that. XML also has the same start- 
and end-tag problem (that I mentioned above) as HTML.

With Apache 2.x (normal CGI), we have: make object! [ 
	server-software: "Apache/2.0.54 (Fedora)" 
	server-name: "localhost" 
	gateway-interface: "CGI/1.1" 
	server-protocol: "HTTP/1.1" 
	server-port: "80" 
	request-method: "GET" 
	path-info: "/sample01.rhtml" 
	path-translated: "/var/www/html/sample01.rhtml" 
	script-name: "/cgi-bin/magic.cgi" 
	query-string: "" 
	remote-host: none 
	remote-addr: "127.0.0.1" 
	auth-type: none 
	remote-user: none 
	remote-ident: none 
	Content-Type: none 
	content-length: none 
	other-headers: [
		"HTTP_HOST" "localhost" 

  "HTTP_USER_AGENT" {Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) 
  Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6} 

  "HTTP_ACCEPT" {text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
		"HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5" 
		"HTTP_ACCEPT_ENCODING" "gzip,deflate" 
		"HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7" 
		"HTTP_KEEP_ALIVE" "300" 
		"HTTP_CONNECTION" "keep-alive" 
		"HTTP_COOKIE" "PHPSESSID=7f84fd7766f23e1462fed550ecbbfda4"
	] 
]

XML madness here !

how can i insert an XML tree inside another ?

As text? Is the XML a DOM tree, parse-xml generated blocks, what?

How is your DOM tree implemented? REBOL doesn't currently have very 
good XML support by default as such. People tend to use text, blocks, 
objects or a combination of them.

the best work on XML parser in REBOL so far, imo, is Gavain Mckenzie's 
script ....

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-parse.r

So it tries to conform to SAX (Simple API to XML) instead of the 
DOM...

I have to admit, I'm awed by the size -- is this the least that it 
will take to get a reasonable XML implementation in Rebol?  And how 
to manipulate and store a SAX structure?

and besides that - look at other XML libraries ... compress your 
script and the size is ok :-)

How to get started with xml? I know the simple things, kind of object-tree, 
similar to what parse-xml does. What extras would be needed?

Volker: user xml-parse+ instead of xml-parse ... you will receive 
block/object structure IIRC ...

Maybe we could start with examples in xml and how they could look 
in rebol? with some dialect for the extras?

Since i can do parsing, but when i look at xml-docu, i do not know 
where to start. If someone could break that up for me..

dunno if much of an overhead, but maybe parse-xml could be used to 
parse even html?

Then we should start there. conversion to xml may than suddenly be 
simple.

so what is the difference basically in when you parse XML document 
using SAX and using DOM?

As programmer not AFAIK. with a dom you can use path-notation. with 
SAX you build that tree yourself. I guess SAX makes sense when you 
convert data, like xml-make-doc. one tag, output something, another 
tag, output something other.

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.

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.

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.

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

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

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

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

>> 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!]]]

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

3) -- xml [doc: load %file.xml elmt: doc/get-element-by-id "foo" 
elmt/tag-name: "p" save %file.xml doc] -- just one example of how 
it might work...

Petr, it's best to know what format you're parsing to before you 
actually attempt to parse.  I'm making the assumption that the results 
of parse-xml, parse-xml+ and xml-to-object are unsuitable for manipulation.

oh, now I understand what did you mean. I thought you are trying 
to somehow "parse XML without actually parsing it", my bad :-)

It is certainly a Rebolish way to look at the XML data, I see a linear 
structure as being more manageable...

Perhaps I don't understand Temple fully, but it doesn't so much manipulate 
an arbitrary XML file, rather pick and choose parts of a larger XML-based 
template?

hmm, dunno of how to explain it. It simply parses XML, creates block 
of blocks structure. Then you have those functions like find-by-id, 
find-by-name, etc., which you can use to manipulate values ... then, 
once done, you generate XML. What I did not like is, that ti builds 
the structure from the scratch, so e.g. with html page, you loose 
nice formatting, comments etc. But others said, you could have pointers 
from such nodes to original doc and rebuild the doc properly ...

Objects aren't a good way to store XML values or even attributes. 
XML attribute names can be specified using characters that are difficult 
to use in REBOL words, like :, and you can't add and remove fields 
from objects at runtime. Hashes are better to store attributes, with 
keys and values of strings. Blocks are best to store element contents, 
with perhaps the none value to specify closed elements.

You might even be able to replace attribute value strings with REBOL 
values if you implement XML Schema typing.

You could then represent other XML data items using a word in the 
tag spot and then type-specific contents. For example:
[comment "comment text"]

Consider the XML document:

<?xml version="1.0"?>
<foobar><foo:bar>Some Text</foo:bar></foobar>

Remember that objects in REBOL have a lot more overhead than blocks, 
and that XML documents can get quite large. Unless you are using 
an event-driven parser, every bit of memory you can save is a good 
thing.

The data structure I am suggesting would be for internal use only. 
You should have a dialect for specifying common XML operations and 
have the dialect processor handle the structure.

I'm trying to figure out the most efficient way to represent the 
XML semantic model in REBOL.

I'm looking at the XML Infoset standard right now.

I understand the need for efficiency, I am also mindful of completeness. 
 The DOM is a complete standard for accessing XML (and I appreciate 
that the 'O' in DOM does not necessarily mean Rebol object! :o)

Bad, bad, bad! Don't use words for element or attribute names, because 
common XML names contain characters that violate REBOL syntax for 
words.

Sunanda, I'm sorry if that was rude :(  As long as the data structure 
can handle the semantics in the XML standards, including extras like 
namespaces and such, then you won't have to extend them.

Assuming that the nesting level of the original XML doesn't blow 
out REBOL's stack limits you can even use an internal recursive function 
with an accumulator parameter.

About the choice of the right internal data-keeping structure: because 
we are manipulating big XML files (> 2MB), we had to find the most 
performant way to retrieve our data into a nested structure. The 
choice was block! / hash! / list! / or object! . after a few tests, 
it appears that block! is the most suitable in terms of retrieval 
time. Note that this is true only for nested structures. In case 
of one-level structures, the hash! is the most performant (see http://www.rebol.net/article/0020.html).

FYI, I have set 2 ppl working on an implementation of XPath into 
our XML function lib (temporary called "EasyXML"). Basically, we'll 
have 5 functions encapsulated into a context: 'load-xml file!, 'save-xml 
file!, 'get-data path! or block!, 'set-attribute string!, 'set-content 
string!

Doing my first steps with REBOL I tried to do something with XML

(reading/eventually modifing/writing). I looked for some scripts 
helping
me to do this and found:

1. xml2rebxml/rebxml2xml:
    I got the following problems:
    - missing/loosing comments
    - missing/loosing elements - that's realy serious
    my steps were:
      my-doc: xml2rebxml read %simple.xml
      write %simple2.xml rebxml2xml my-doc


    The second documents finishes outputting elements after some comment
    block in
     the source xml doc.

 2. xml-parse/xml-object:

     The versions I found on the reb library didn't work, I used some

     older versions from rebXR-1.3.0, I've got my objects, but it would 
     be

     nice to have a third module like xml-write to get the object tree
     back to xml. Is somebody developing something like this?

 3. mt.r:

     I tried to figure out how it works. Basically I can write some XML

     based on a REBOL block but I couldn't figure out how to define the

     rules about elements and attributes. Where can I find an example

     about writing for instance svg with mt.r, how looks the coresponding
     REBOL block and the rules for svg?


Where can I find more about xml and REBOL, I think it would be very 
nice
to have some REBOL scripts, doing things like 
   some-elem: xml-create [ elem "foo" namespace "myns" attribs [
                                     bar "something"
                                     xyz "123"]
                                     ]
   xml-modify [ elem another-elem append some-elem ]
and finally
   xml-write %mynewxml.xml my-doc


Is somebody developing something like this with REBOL? Some scripts 
giving

me the same comfort in REBOL like maybe XOM (http://www.xom.nu) is 
giving
for XML in Java. Of course done with some nice REBOL dialects?

What is the above mentioned "EasyXML" - is it available for use/testing?

Thank you for any tips, carsten

One more thing about XOM: E.R Harold has collected a lot of test 
XML files with many sophisticated XML things that can happen regarding 
to the XML 1.0 specs.

Carsten, xml2rebxml should be able to handle comments. Are you sure, 
your simple.xml is valid xml?

By "handle", I mean parse them, but comments ain't in the output. 
The script shouldn't stop for valid XML input.

I played around with some shorter XML document, to figure out, how 
it works - my REBOL experiences are from last week, so maybe I'm 
doing something wrong. The comments will be parsed and the block 
looks also complete but during writing it stops after an element 
that is followed by some comments. So far as  I have seen these comments 
are left out in the block but there are a lot of whitespaces between 
the last printed element and the next missing element.

I will try the new xml2rebxml.r, I think it would be nice to preserve 
the comments. If somebody writes xml in a text editor and makes some 
annotations, so it its nice, if he gets these comments back after 
processing the files with some other (REBOL) tool. But this feature 
has some lower priority.
I found some more thing in xml2rebxml.r, only the entities
      replace/all att-data ">" #">"
      replace/all att-data "&lt;" #"<"
      replace/all att-data "&amp;" #"&"
will be replaced,  the other two are missed, I think:
      replace/all att-data "&quot;" #"^""
      replace/all att-data "&apos;" #"'"

What is wrong with XML apis - http://www.artima.com/intv/xmlapis.html

Carsten, you're right about the " and '. As I read the 
DTD (http://www.w3.org/TR/2004/REC-xml-20040204/), those can only 
be found in attribute values (see [10] AttValue), not in character 
data (see [14] CharData). Is that correct?

I liked the discussion Chris and Brian hold here week or so ago ... 
simply let's find a way of how to work with XML in rebol - once we 
know what do we want, we can start coding ...

Would it make sense to have XML files be represented as a port like 
xml:// . This could make sense for DOM and for SAX. But please correct 
me if that's stupid. For SAX this would enable one to copy from the 
port and get events by copying, for some one could navigate with 
some dialect and position the cursor in the document. A copy would 
read the data at the current positon - but then a block or something 
which represents an element could be returned. But I guess that's 
not well thought out. :-)

Carsten, I've added suport for " and ' in xml2rebxml. I've 
also added preservation of comments, if xml2rebxml is called with 
/preserve refinement (just call it like: xml2rebxml/preserve <xml 
code>). I've uploaded the scripts to my page: http://home.tiscali.dk/john.niclasen/rebxml/

I think, they need some testing, before they go to the library at 
www.rebol.org.

John, I've downloaded it from your website - thank you!

One more question from an unexperienced REBOL-user:

What is the most commen way to enhance a block I've got with xml2rebxml, 
source is
<?xml version="1.0" encoding="iso-8859-1"?>
<chapter id="ch_testxml" name="Test XML">
  <title>A chapter with some xml tests</title>
  <sect1 id="sct_about" name="About my Tests">
    <title>What kind of tests I will do</title>
    <body>
      <para>Some simple paragraph.</para>
    </body>
  </sect1>
</chapter>

After read in the file with
my-doc: xml2rebxml read %test.xml

I'd like to insert a second sect1-element in the block my-doc, whats 
the best way - just to avoid some stupid mistakes.

Thanks Carsten, that clarifies things clearly to me .... I like Sax 
aproach more too .... IIRC Gavain's stuff was Sax like too ... it 
just could not write back to XML ...

I was fighting today to find the best internal data format. Out of 
the tests seems object! the most performant when using nested data 
structure. hash! when not nested. but the problem with object! is 
that we cannot have a recurrent element in the  structure, like:
<aaa>
   <bbb>content</bbb>
   <bbb bbb_attrib="attrib1"></bbb>
</aaa>

because, of course, when evaluated the last definition of bbb overrides 
the others.
So, we are trying to work with hash!

We got a little diminution of the overhead comparing to XML, but 
the processing time compare to block! seems from 10 to 20% more.

I need some more tests about data retrieving in the structure to 
find the right combination;
Any suggestion is welcome !

carsten: I should have kept my mouth shut about XOM and asked you 
before :-)

the port-idea was just that a thought - in any case if one wants 
to use a dialect there has to be an entity to interpret the dialect, 
whether that's an function or something else doesn't matter, but 
a port seams to be a common rebol entity to encapsulate things - 
that's why I thought it would maybe even make sense to use a port 
as abstraction .... opening a port to an xml file and the port will 
parse it in whatever way - by sending (inserting) a dialected block 
into the port the xml document could be worked on - at least from 
the users point of view one wouldn't have to handle the xml-code-block/rebol 
code block separetely - even though it might be nice to access it 
directly .... well maybe I have too little glue about ports so the 
idea might not make too much sense when I forgot about some important 
drawbacks and the like

to michael:

maybe you can show some rebol pseude code, how to read all chapters 
from a book.xml file, so we had some nice use case to think about

... using a XML port

to John (or geomol),

first I've got the following error:
>> my-cdoc: xml2rebxml/preserve read %short.xml
** Syntax Error: Invalid word -- -->
** Near: (line 9) -->

So I replaced
  insert tail output load join "<!--" data
with
  insert tail output join "<!--" data
and it works fine with my files!


You were right, the replacements in text nodes are only &amp; &gt; 
&lt;. In attributes we need to escape the other 2 entities as allready 
done by you.

Good points, Maarten about accessibility.


If I were looking for an alternative REBOL GUI and typed REBOL GUI 
into Google, I'd probably soon conclude that there wasn't one. And 
that might end my evaluation of REBOL.


Having many useful tools scattered across personal websites has other 
weaknesses too -- look at how hard it's been for people to find Gavin 
MacKenzies's XML libraries after his personal website went offline.

part of my jog nowadays is get into XML, XSLT and that stuff ... 
we just upgraded SAP, and it generates some docs for us, which are 
ok in IE, not in FF (totally screwed) and on friday I visit IBM to 
see XForms and I will ask those guys, if it makes sense to go that 
route ... it seems like going to hell ... :-)

Pekr, given your level, what is there to learn in XML.  "you" site 
down for 1 hour, read about, furrow your eyebrow, and your done.

Reichart - have you ever looked into stuff like transformations? 
If XML was all that easy as you suggest, how is that we don't have 
proper SAX or DOM parser in rebol - those supporting libs are sometimes 
larger than Core itself - I wonder, if it was intention of its creators 
......

It also renders JavaScript, and XML, and CSV, and SMS, and Email, 
etc.

Was just checking it a little bit, and it looks that the mtasc is 
pretty complicated. First action script I wanted to compile using 
mtasc was not compiled successfully:) The biggest difference is, 
that the mtasc is only ActionScript compiler, but in my dialect one 
can compile everything (shapes, sprites, images, sound). You must 
use swfmill or how they call it to compile such a things (and it's 
using XML so I thing it's not much useful for making complete application 
in it (as I do).

I still have a lot of things to imrove on my Flash compiler.. I don't 
want to play with some XML toy which can need ages to be available 
on so many computers as Flash is now

Using rebol to call mxmlc.exe and deliver it some Rebol generated 
xml gives you a Flash 9 .swf file all set to go.. kinda cool.

To give you an example.. this.. 
<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"layout="absolute">

<mx:Panel title="My Application" width="200" height="300" x="0" y="0">

<mx:Label text="Welcome to Flex!" mouseDownEffect="WipeRight" height="45"/>


</mx:Panel>
	<mx:PopUpButton x="483" y="20" label="PopUpButton"/>
	<mx:Accordion x="441" y="50" width="200" height="200">
		<mx:Canvas label="Accordion Pane 1" width="100%" height="100%">
		</mx:Canvas>
		<mx:Canvas label="asdf" width="100%" height="100%">
		</mx:Canvas>
		<mx:Canvas label="asdf" width="100%" height="100%">
		</mx:Canvas>
		<mx:Canvas label="adsf" width="100%" height="100%">
		</mx:Canvas>
	</mx:Accordion>
	<mx:CheckBox x="441" y="258" label="Checkbox"/>
	<mx:DateChooser x="238.5" y="31"/>

</mx:Application>

Konfabulator widgets are more comparable to regular reblets running 
in View. Just because they are implemented in XML/CSS, doesn't mean 
they are held to the same behavioral standards as web pages.

general? Rebol general,no? maybe XML-RPC would be interesting for 
non-rebol world, but it could be added too ....

Petr: RSP can emit XML if you need to separate content from presentation. 
Btw, I'd be happy to see an XSLT lib done in REBOL.

Pekr: There's a lot of competing templating solutions, and AFAIK, 
XML+XSL is the most used one. You can also look at Enhydra XMLC here 
: http://www.enhydra.org/tech/xmlc/index.html(It's done with JSP, 
but the concept can be easily ported to any other language).

yes, it is just ... what is xml good for here? :-)