AltME groups: search

In the ancient (!!) rebol.org snapshot I have locally, I counted 
11 occurrences in 8 files (blog, new-blog, make-doc, make-doc-pro, 
makedoc2, json, translate, xml-dom) in a total of ~1000 files and 
255k lines of code.

The DrDobbs link led to this one - After XML, JSON: Then What?


http://www.drdobbs.com/web-development/after-xml-json-then-what/240151851


That article mentions that one of the "most interesting" new data 
formats being considered is TOML (this looks like the .ini file format)

https://github.com/mojombo/toml

Is this really what we can expect?

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

We'll step by step abstract all those little details, so you'll be 
able to specify your whole app parameters from Red only without having 
to touch any Android XML file.

@Giuseppe,: No, wiki software is mediawiki, to have a good support 
 multilanguage you have to install a mediawiki for every language. 
I just adopted http://www.informe.comfree solution ready to use; 
and I haven't many option as superuser. However creating and importing 
pages is easy. If you have already a wiki, export pages in a XML 
file, and I'll import the pages.

I had the same argument as you with a boss of a company, I did free-lance 
work for. I was able to convince them to buy REBOL/Command though, 
because the develop time went down by a factor 10 or so.


A bit along the same type or argument, I convinced a business partner 
of that company to implement XML-RPC instead of using SOAP based 
calling method across the internet. It saved us months of development 
time, and the other company could implement XML-RPC feature within 
days.


Just keep on arguing, also from a cost viewpoint. Don't give in! 
:) It pays.

Thanks for posting that link Ted!


I, too, want an all-REBOL toolchain and format. However, I view MD/MDP 
as a very basic format for plain communication and HTML generation. 
It is not a "structured" document format.  And while extensible is 
good, we can probably come up with a spec that outlines all that 
might need to be handled, to help guide a baseline design. e.g., 
while it's XML, DocBook was well thought out IIRC.


I admit that one of my problems with makedoc, historically, is consistent 
behavior and support for images and links. 

Don't forget Gab's QML either.

Robert: "The cool thing with this approach is one really don't need 
anything more than the Android encapper to produce the apk file. 
No need for android NDK, SDK or even JAVA to be installed ;-)"


Do I understand you reimplemented jarsigner, zipalign and the java 
XML binary compiler in Rebol?

Arnold, you can also take a look at an .xml file that Excel produces 
and see how that is configured. I've had better success with xml 
files than csv (though I use those as well) since you can add all 
kinds of formatting with XML.

@kaj and balance-line through the files. A possibility, has some 
tricky attentionpoints in it, and the preferred way when efficiency 
is in the picture or more than once usage. Db seems to be pretty 
straight forward and its a nice exercise in using that.
Thanks Endo, I mailed the links to my work.

@James To me xml just looks like a whole lot of <> characters and 
a lot of description extra. Having to deal with that too seems a 
lot of work more, need a tool for  working quick with xml.
Thank you for all of your suggestions!

There are several XML parsers for REBOL. The most advanced one is 
in the PowerMezz package

we neededed to support, xml rest, SOAP and direct get/post interface 
to the same functions, and that is now working via a configuration, 
which allows you to tweak how the url is read and switch interfaces 
on the fly.

damn! no luck.

>> ls
BSD-License.txt  change-log.txt   clients/         docs/
handlers/        libs/            protocols/       services/
uni-engine.r
>> uniserve-path: %./
== %./
>> do %uni-engine.r
Script: "UniServe kernel" (17-Jan-2010)
Script: "Encap virtual filesystem" (21-Sep-2009)
== true
>> uniserve/boot
booya
.

http://newsrss.bbc.co.uk/rss/newsonline_uk_edition/business/rss.xml
** Script Error: Cannot use path on none! value
** Where: process-task
** Near: if any [
    zero? shared/pool-max
    shared/pool-max > shared/pool-count
] [fork]
either

Just trying to look up prices based on SKU.  This is the string I 
have so far:


http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=[mykey]&Operation=ItemLookup&ItemId=041554286915&IdType=SKU&Timestamp=2013-03-19T10:04:31Z&Signature=[this-is-what-I-need]

Which script do you suggest me to use for parsing XML files for R'? 
There are many on rebol.org.

I mainly want XML to object, so I can export data from .xlsx file. 
XML to blocks might work but I may need to work on objects for more 
functionality.

If I remember correctly, you can't go 1 to 1 from xml to object. 
You can to block.


I've only used my xml2rebxml.r, which produces a block. You could 
work from there, pull out the elements, you need, and produce an 
object.
http://www.rebol.org/view-script.r?script=xml2rebxml.r

Chris: is that normal?
>> load-xml {<si><t xml:space="preserve">test</t></si>}
== [
    <si> [
        <t> [
            #space "preserve"
            %.txt "test"
        ]
    ]
]

I see, I just confused if it's a bug or not.
>> load-xml {<a>test</a>}  ; == [ <a> "test" ]

>> load-xml {<a b="c">test</a>}   ; == [ <a> [ #b "c" %.txt "test" 
] ]

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.

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

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.

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? :-)