Robin Berjon wrote:

Michael A Nachbaur wrote:

On Wednesday 19 November 2003 12:47 am, Robin Berjon wrote:

Do you have specific technical ideas that we should work on to
facilitate this?


In my (short) experience building Mozilla+XUL applications, the thing I noticed the need for most was RDF input.


I'm confused :) You say RDF input here, but then later all you talk about is RDF output. Or is it RDF output from AxKit that's input to Mozilla?


AxKit -> RDF -> Mozilla

It is true that RDF input (to AxKit) is hard, because of the flexibility of RDF's expression in XML. The same statement can be said in many ways, and that requires a specialised RDF parser. We don't currently have that in AxKit, and it would be really nice to have it available as a Provider (possible one providing a canonical view of RDF so that it'd fit better into the whole pipeline, which easier XSLT processing and so on).

If your problem is outputting RDF/XML from AxKit, then it really shouldn't be that hard (as you note later). Honestly, if you're talking about 4000 statements, that doesn't seem like much at all. True, with XSLT you have to output it all at once, but it's *really* fast, and the IO may actually be simpler (ie faster). If your current stuff is slow, you should give LibXSLT a try, it still surprises me sometimes :)


Yeah, I'm using LibXSLT, but I was still seeing some pretty odd delays. The main issue was not in the actual load time, the three seconds it was taking being quite acceptable. It was the percieved load delay, since several RDF data sources were being loaded simultaneously and delaying the rendering of the "Intro" screen, so to speak. This is really just an implementation detail, but the thing that chafed on me was the tedious nature of outputting RDF with it's heirarchial ID tags, and so forth.

This application was a "Wowzer!" prototype application, the sort you show to your boss to try and dazzle him with bullsh*t so he'll give you the budget to write the application you want (and make it OSS in the end). The percieved load time was a big thing that won me the project, even though in production it probably wouldn't be done that way anyway.

So, anyway, to answer the question, I would like to see better support for outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result of an XSL transform, but somehow that never occurred to me before.


If you have specific needs going from an RDF model to its XML expression, then AxKit is lacking, but if it's just generating XML then you should have all the tools :) If the former, you might want to look at http://search.cpan.org/~zooleika/RDF-Simple-0.04/ which is a nice package despite the fact that it uses TT2.


:-) I would actually like to round-trip RDF. I have three main paths I could take for building my app: a) have a Mozilla interface act as a web-service client, b) have the interface just scrape values from raw XML outputted from AxKit, or c) round-trip RDF to-and-from Mozilla, feeding RDF to the client interface that describes form values, and then taking the resulting RDF and updating the necessary database values as they're changed.

I still don't know what the "Best" way of doing this would be, as several fires have broken out and I've had to resort to my more baser abilities (http://nachbaur.com/software/reproxy/), but I would like to investigate the possibility of either an RDF scrubber like you describe above, or a Web Service provider of some sort.

Right now, the only way I can forsee really leveraging AxKit's abilities for interacting with the Mozilla client is to do option (b), scraping raw XML, which isn't actually that difficult, AFAICT.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to