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