Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

REBOL and XML

 [1/13] from: sunandadh:aol at: 15-Mar-2003 5:03


Hi there (didn't spot a name in the email) [was REBOL Flash and Browsers]
> If you want to push Rebol, get it working with > messages and email in or with the browser > along with it's own desktop browser with xml, > xhtml, and it will be noticed.
Sounds like you've been quietly plugging away in the background doing some great work!! Any chance of publishing some of the tools you've developed? I spend about 20% of my IT time working with things like Cocoon. XML, XSLT, stuff like that. That's a serious happening world, and it is all centered on XML. <aside>Personally, I'm not that happy about XML. It's hierarchical, and the world is making many of the same mistakes that IBM made 30 years ago with its hierarchical database IMS (I hope I'm the only one on this list sad enough to remember virtual-logical child pointers and the other heroics needed to merge two hierarchies built upside down from each other. XSLT's axes feel horribly familiar after that). We were saved from hierarchical data by the relational model (not that that's perfect -- but that's another story).</aside> Vast swathes of the world's more active data is moving to XML. A language that doesn't support XML in the same seamless manner that it supports flat files is going to look very quaint before long. The REBOL community has developed a few tools, but as Bryan wrote the other day "I think RT has voiced the attitude that Rebol is also data and this seems to have led it to look down on xml." If true, that's a real pity. REBOL could be just the silver bullet the XML world needs to make handling XML a joy rather than about as fun as hand-carving HTML (I do a lot of that too). But at the moment there is almost no overlap between the two worlds. Or so I thought until I saw your post!! Maybe there's hope for us yet :-) Sunanda.

 [2/13] from: bry:itnisk at: 17-Mar-2003 10:05


>Sounds like you've been quietly plugging away in the background doing
some
>great work!! Any chance of publishing some of the tools you've
developed? I would definitely like to see the xmldom there, not to mention the xhtml browser.
>I spend about 20% of my IT time working with things like Cocoon. XML,
XSLT,
>stuff like that. That's a serious happening world, and it is all
centered >on
>XML.
Very serious, and perhaps as important as protocols in most developer's worlds. You might like to look at gavin mckenzie's xml stuff http://www3.sympatico.ca/gavin.mckenzie/ and for some context on this: http://mail.python.org/pipermail/xml-sig/1999-December/001709.html
><aside>Personally, I'm not that happy about XML. It's hierarchical, and
the
>world is making many of the same mistakes that IBM made 30 years ago
with >its
>hierarchical database IMS
I disagree with this, for too many reasons to go into what with work to get to.
>Vast swathes of the world's more active data is moving to XML. A
language
>that doesn't support XML in the same seamless manner that it supports
flat
>files is going to look very quaint before long.
Indeed.
>If true, that's a real pity. REBOL could be just the silver bullet the
XML
>world needs to make handling XML a joy rather than about as fun as >hand-carving HTML (I do a lot of that too). But at the moment there is >almost >no overlap between the two worlds.
It's sort of depressing for me; I have no time to focus on improving my Rebol skills because of requirements for shipping version 1 of our content management system, at the same time much as I appreciate the structure of the language the difficulties of handling markup with it make it seem increasingly tertiary to my actual needs, while the licensing of rebol make me consider it not useful for anything but small scripts.

 [3/13] from: sunandadh:aol at: 20-Mar-2003 5:37


Bryan:
> Very serious, and perhaps as important as protocols in most developer's > worlds. > > You might like to look at gavin mckenzie's xml stuff > http://www3.sympatico.ca/gavin.mckenzie/
Thanks -- Gavin's done some quality work there. But it has limitations. Though they may be inherent in REBOL being a "small systems" langauge. xml-object.r is Rebol block based so it is limited in the size it can handle -- the limitations are machine and opsys dependant but (on my machine) is only around a couple of hundred megabytes. xml-parse.r -- unless I'm reading too much into it being SAX-like, it gives me a one pass through the structure with no signnificant size limitations, but without my ever having the full picture or being able to vary the nagivations. It'd be great to have XML! as a native REBOL datatype with no significant memory limitations. And a REBOL-based XSLT processor. Then we could take over the world!! Sunanda.

 [4/13] from: g:santilli:tiscalinet:it at: 20-Mar-2003 12:17


Hi Sunanda, On Thursday, March 20, 2003, 11:37:56 AM, you wrote: S> It'd be great to have XML! as a native REBOL datatype with no significant S> memory limitations. And a REBOL-based XSLT processor. Then we could take S> over the world!! How should such a datatype behave? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [5/13] from: sunandadh:aol at: 20-Mar-2003 6:46


Gabriele:
> How should such a datatype behave?
Good question! I'd like to be able to navigate it just as I would a complex nest of blocks or objects -- next back skip copy etc. I'd like to be able to go up to parents and down to children -- so axes navigation but better thought out than under XSLT.. I'd like to be able to sort branches, prune them, move them around. And use 'find and 'replace of course. All the things I can do with flat files, blocks and lists: but built into REBOL with all of Carl's usual flair for design simplicity. Sunanda.

 [6/13] from: bry:itnisk at: 20-Mar-2003 12:31


>It'd be great to have XML! as a native REBOL datatype with no
significant
>memory limitations. And a REBOL-based XSLT processor. Then we could
take
>over the world!!
I definitely want a rebol-based xsl-t processor at some point, but I think that would only be useful in the context of a rebol framework for easily building processors for different xml-based languages (dependant of course on one's definition of 'easily') The idea of having a rebol xhtml/html browser is of course good, because then one could have the browser receive input from an xsl-t process. When you talked about rebol being seen as somehow quaint without strong xml facilities I can't help but agree, my development needs are most strongly focused on controlling markup nowadays. Rebol may make the protocol stuff simple, but this is no longer the most important part of my day.

 [7/13] from: g:santilli:tiscalinet:it at: 20-Mar-2003 13:14


Hi Sunanda, On Thursday, March 20, 2003, 12:46:00 PM, you wrote: S> I'd like to be able to navigate it just as I would a complex nest of blocks S> or objects -- next back skip copy etc. So if you had: test: to xml! { <a> <b/> <c> <d/> <e/> <d/> </c> </a> } what would you expect the standard actions (FIRST, NEXT, PICK etc.) to do on TEST? Re: size of data, should something like: test: to xml! %data.xml work on the file instead of loading the data into memory? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [8/13] from: bry:itnisk at: 20-Mar-2003 13:23


>How should such a datatype behave?
Am not sure as to a datatype for an xml instance being useful, if there were such a thing it would probably be related to the infoset: http://www.w3.org/TR/xml-infoset/ It seems to me that if there were to be an xml datatype there would actually be at least two: one for well-formed xml and one for malformed xml. So two markup datatypes. Load a html page, check datatype, if badMarkup run markup cleaner function if goodMarkup call xhtml-browser.r with html page. And so forth. However I think that having a datatype for an xml instance itself is not too useful. The xml specification has a number of basic 'xml' datatypes anyway. An ID could be considered as an xml datatype, an entity another, anything in the xml: namespace is generally discussed as being an xml datatype. Am going to eat lunch now but I would like to discuss more on this issue. As an aside there has been a recent thread on xml-dev on how insufficient most XML-APIs are for dealing well with xml, which I don't think is necessarily so, however as this is an area for widespread dissatisfaction if rebol were to provide a credible way of handling xml it could help spur an influx of very smart people to the community.

 [9/13] from: bry:itnisk at: 20-Mar-2003 14:11


><a> > <b/>
<<quoted lines omitted: 4>>
> </c> > </a>
Needs to be more like: test: to xml! { <a att="some text here"> <b/> <c> text <d att="d att"/> <e/> <d/> text </c> </a> } according to xpath 1.0 which has it's own datatypes for this kind of thing: there is a root element / / has one child a, known as the document element a has one attribute and two child nodes, one of these elements b is empty, c has children. c has two text nodes, and one element node d which has an attribute the value of which equals d att and an empty element e. various xpaths: xpath1 = "/" returns the xml instance from the document element, i.e a xpath2 = "/a/@att" returns the att attribute of a xpath3 = "/a[@att/d]" returns d as a direct child of a, which there isn't any of. Xpath4 = "//d" returns any d in the document Xpath5 = "//d[@att='d att'][e and not(text())]" returns any d in the document that has an attribute att the value of which equals d att, has a child element e and does not have any text() nodes. Xpath6 = "//d[parent::c]" returns any d which has a parent node c And so forth. This could have been complicated by using sibling examples and namespaces but this is a good start. Xpath is in my opinion pretty simple and an example of a highly successful way of working with xml data, it is used in various dom implementations and streaming apis, as well as xsl-t. There are approved mechanisms for extending xpath dependant on its implementation environment. Dependant on implementation one can as a general rule follow an xpath to a position within the xml instance and from there use a different xpath to navigate to another position relative to current context. A representation of xml as blocks and using rebols block navigating syntax, nor the basic syntax for doing picks etc. does not seem to come close, however this could just be caused by my seeing things which for me are especially easy with xpath over xml due to my expertise as being difficult with rebol over xml as a block due to my ineptitude. Any clarification on how one would do these things would thus be much appreciated.

 [10/13] from: bry:itnisk at: 20-Mar-2003 15:05


>various xpaths:
sorry I seemed to have some formatting errors or just mis-typed, don't know what happened but xpath3 should have been "/a[@att]/d"

 [11/13] from: sunandadh:aol at: 20-Mar-2003 12:19


Gabriele:
> what would you expect the standard actions (FIRST, NEXT, PICK > etc.) to do on TEST? >
I'd expect behaviour similar to that of XSLT -- though perhaps not quite the same --XSLT is (basically) derived from Haskell and so is pure-functional, side-effect free. That leads to (in my opinion) very convoluted programming to do simple things. So I'd expect the behaviour to make sense when compared with the same function on a list or block. Plus we'd need a few extra navigation controls for parent or next-child-within-parent. Of course those sorts of controls can get inelegant and messy. As I've said before (and Bryan disagrees) strictly hierarchical structures are a big mistake. But they are a dominant data format for information interchange.
> Re: size of data, should something like: > > test: to xml! %data.xml > > work on the file instead of loading the data into memory? >
A neat way to do it would be to make XML! analogous to File! I can open it in memory -- that gives me a full set of DOM-style functions. Or I can open a port -- that gives me bigger data structures while being limited to SAX-style navigation. As you can see -- I'm not answering your questions in terms of precise expectations and syntax. It's maybe too early to tie down what an XML! data type (or XML scheme) should do. I'd just like to underline the point that REBOL will be better prepared for today's data structures once it has industrial-strength XML handling. That doesn't have to be built into the language, of course, we could do it ourselves as a collaborative project. Though it'd be a big plus if it was. Sunanda.

 [12/13] from: bry:itnisk at: 20-Mar-2003 19:03


>As I've said >before (and Bryan disagrees) strictly hierarchical structures are a big >mistake. But they are a dominant data format for information
interchange. I disagree from a point of what I would normally consider atrocious logic, that is to say I don't think they are a big mistake BECAUSE they are a dominant data format. Or to put it in a less tautological way, I believe hierarchical structures are a dominant data format, and a recurring way of formatting data, because hierarchies are ingrained in human consciousness as a primary way of understanding reality, thus even if technological constraints for a period of time makes a relational, tabular, or flat structure better I suppose that the need for and resurgence of a hierarchical structure will always be achieved by the tendency of humans to 'hierarchisize'. Must be a word for that somewhere.

 [13/13] from: SunandaDH:aol at: 20-Mar-2003 14:48


Bryan:
> I disagree from a point of what I would normally consider atrocious > logic, that is to say I don't think they are a big mistake BECAUSE they > are a dominant data format.
Thanks for the clarification. I don't think we are disagreeing where it matters. XML as a data exchange mechanism is becoming ubiquitous, so (whatever the limitations of hierarchies) REBOL will be better positioned for the future if it supports XML in a wholehearted way. It's like when American robber John Dillinger was asked why he robbed banks. He (apocryphally) replied: "because that's where the money is". Modern languages need to support XML because that's where the data is. In fact, given that REBOL can see beyond hierarchies, it has a lot to offer the world of XML transformations. With the right tools, we could take an XML file, and apply magic transformations behind the scene in ways that would leave an XSLT expert awed and humbled :-) Sunanda.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted