ANNOUNCE: Zope/XML Roadmap
Fellow Zopistas, A number of community members have been discussing XML in Zope and some folks have actually released Zope/XML products. Go team! In the next couple days Digital Creations is going to release an alpha of an XML Document object, and I want to take this opportunity to let you know about it, and summarize what our XML plans are. -- XML Document Product alpha What started as a hack while sitting around Paul Everitt's kitchen has become useful enough to release. XML Document is a Zope product which will provide support for handling XML objects in Zopish ways. We plan on releasing the first alpha before the end of the week. It will be an unsupported product and will not be an official part of Zope 2. What is it? XML Document is a Zope product that allows you to use xml objects in Zope which expose their internal structure in a Zopish way. You can, * Format xml objects with DTML, you can even use the tree tag with xml objects. * Publish xml elements via URL traversal. XML elements work like normal Zope objects so for example, they can acquire DTML methods for display. * Edit xml objects using the management interface. XML Documents allow you to edit sub-elements individually if you wish. * Query xml objects using the DOM API. * Catalog xml objects. You can catalog XML Documents, and even individual elements in a document. * Create very large documents. Since elements are normal persistent objects, Zope does not always need to keep the entire DOM in memory. More information will be available when it is released. And now on to a more broad look at what we're planning. Please note that these are merely plans, not promises to deliver. We are serious about welcoming feedback and participation from the community, and don't wish to preempt any work others are doing. We just want to let you know what we're thinking about, and ask for comments. -- Zope and XML Roadmap This is summary Zope/XML activities and plans. What's available now? XML Development XML Document Product (available soon) XML Document is a Zope product that allows you to use xml objects in Zope which expose their internal structure in a Zopish way. XML Document provides fairly generic support for XML, and can be subclassed using ZClasses to build more specific XML applications. XML Document is currently an alpha quality, unsupported Zope Product. XML-SIG xml package Python has excellent XML support which is developed and maintained by the XML-SIG. While Zope does not come with this package, you can use it with Zope by either installing normally with the Python you use to run Zope, or installing it in 'lib/python1.5' if you are using a binary Zope installation. The xml package gives you access to a wide range of tools which you can use to develop XML applications via External Methods or Zope Products. You can even build ZClass base classes in Python which use the xml package and then create ZClasses through the web. http://www.python.org/sigs/xml-sig/ XML-based Standards Support WebDAV support Zope supports remote content management through the WebDAV protocol. http://webdav.zope.org/ XML-RPC In addition to Zope's native URL to method conversion, it supports XML-RPC. This support is built into the Zope ORB. http://www.xml-rpc.com/ Where is XML support in Zope going? There's no telling where the energetic Zope community will take Zope, but here is a tentative plan for what Digital Creations hopes to do. DOM support for Zope objects Work is underway to add DOM methods to standard Zope objects (aka SimpleItems and ObjectManagers) This will essentially make the Zope object hierarchy available as though it were a large XML document. At first the DOM support will be read-only, with DOM methods to manipulate the Zope object hierarchy coming later. It may make sense to change the Zope management interface some to make it more congruent with the DOM. For example, right now there is now way to explicitly re-order child objects within Folders using the management interface. http://www.w3.org/TR/REC-DOM-Level-1/ XSL as an object query language for Zope Once Zope objects support read-only DOM methods it should be fairly simple to allow Zope to be queried with the pattern subset of XSL. We plan to use an existing xsl implementation, rather than write our own. http://www.w3.org/TR/WD-xsl/ Further refinement of XML Document Product The XML Document needs a lot of work, * Verify that the DOM implementation is fairly complete and correct. * Start using the forthcoming version of pyexpat which will allow more complete parsing, including comment nodes. * Add PUT and FTP support to allow remote editing of XML. * Improve performance. In the longer run plans include, * Provide an ability to bind ZClasses to specific Element types. This is similar to ZSQL Method's notion of brains. * More completely support Zope management and object protocols. * Provide XML validation services. I think that Zope is going to turn out to be a very exciting platform for XML work. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com
Amos Latteier wrote: [snip XML roadmap] Ooh, I just wrote off a post wondering where the XML roadmap was, but here it is. I shouldn't send out messages before looking, obviously. :) Thanks! Now I'll go read it. Regards, Martijn
Amos Latteier wrote: [snip XML roadmap] Now I read them. It's funny; here I am walking around, getting more and more neat ideas on how to how to use XML in Zope, turns out Maik Roeder wrote an External Method that does much of what I was thinking about already, and the Digicool people already were a few steps ahead of me with their ideas and implemented an XML Document. Just this morning I was figuring out that you'd need an 'Ordered Folder' to represent XML documents in Zope neatly, and it turns out they thought of *that* too, already, and are planning to adjust the management interface to support them! Can't I think of something original for a change? :) Anyway, an Ordered Folder can be useful independent from XML -- you guys want to change the management interface, so I presume you want all Folders to become ordered. I think this would be useful anyway for many non XML-ish tasks, like a folder containing news messages (ordered by posting date), or FAQ questions, or something similar, and it doesn't seem as if there'll be many backward compatibility problems, so I suppose that's the best idea. Regards, Martijn
At 10:36 AM 7/21/99 +0200, you wrote:
Anyway, an Ordered Folder can be useful independent from XML -- you guys want to change the management interface, so I presume you want all Folders to become ordered. I think this would be useful anyway for many non XML-ish tasks, like a folder containing news messages (ordered by posting date), or FAQ questions, or something similar, and it doesn't seem as if there'll be many backward compatibility problems, so I suppose that's the best idea.
Actually, as I recently found out from Jim, ObjectManagers are already ordered. It's just that you can't manipulate that order. -Amos
Amos Latteier wrote:
At 10:36 AM 7/21/99 +0200, you wrote:
Anyway, an Ordered Folder can be useful independent from XML -- you guys want to change the management interface, so I presume you want all Folders to become ordered. I think this would be useful anyway for many non XML-ish tasks, like a folder containing news messages (ordered by posting date), or FAQ questions, or something similar, and it doesn't seem as if there'll be many backward compatibility problems, so I suppose that's the best idea.
Actually, as I recently found out from Jim, ObjectManagers are already ordered. It's just that you can't manipulate that order.
Ordered alphabetically (by id), or is that another order imposed on top of things? Anyway, if they're already ordered then of course changing the management interface is the way to go. Regards, Martijn
In article <3.0.5.32.19990721113322.00cfe470@mail.aracnet.com>, Amos Latteier <amos@aracnet.com> wrote:
Actually, as I recently found out from Jim, ObjectManagers are already ordered. It's just that you can't manipulate that order.
I take advantage of that fact in my Zope Pilot Desktop project. The Desktop-representing object is a folder subclass with order management (important to control the order that the contained conduits will be run during sync).
At 01:42 22/07/99 , Ty Sarna wrote:
I take advantage of that fact in my Zope Pilot Desktop project. The Desktop-representing object is a folder subclass with order management (important to control the order that the contained conduits will be run during sync).
Pilot? As in Palm Pilot? (MJ Flaps his ears and waves his new IIIx). Can you tell us more? -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
In article <4.2.0.58.19990722122859.00d6c2e0@lisp.atmm.nl>, Martijn Pieters <mj@antraciet.nl> wrote:
Pilot? As in Palm Pilot? (MJ Flaps his ears and waves his new IIIx). Can you tell us more?
Sure... here's a little prepared explanation. It's a bit out of date now, but the basics are there. Note that progress is pretty much stalled while I finsh up some paying gigs and relocate. Also, ZClasses, the Catalog, and other developments have some interesting implications, and I need to think about those before I continue. I expect to get back to it in the early fall. --- Since I first saw Principia, I've been think about what sorts of interesting applications it could be used for. Some things are obvious, like trouble ticket systems and community portals. But I've been wondering what kinds of programs could be written as web applications that traditionally never have been. I've got 3 interesting ideas so far. One I came up with is something I needed anyway, a good "desktop" for the Palm Computing Platform. pilot-link is very, very basic. KPilot is not very extensible. But a Zope-based desktop has some interesting benefits. First, it's easy to extend. Second, it's a GUI appliction (albeit not with the slickest possible interface, due to the limitations of html), without introducing the problems of portability or all the labor required for a traditional GUI. Third, it means not only can you take your data on the road in the pilot, but you can also access it on the road via a web browser. Fourth, you can sync over the web, if you have appropriate client software and a cradle on the local end. Since I'm making good progress on it now, I though I'd share a sneak peak. Here's what I have so far. The architecture consists of two parts: a sync client and the desktop. The sync client needs Python 1.5.2, the pilot protocol libraries from pilot-link, and part of Rob Tillotsen's Pyrite interface to those libraries (I use his basic DLP stuff and record packing/unpacking stuff, but I did my own conduit framework that's a little different). Individual conduits are implemented in separate modules. The other part is written entirely as a Zope product that provides several different kinds of objects. This part is currently called "Dezkset", becuase I can't think of anything better. Suggestions for a better name would be appreciated :-) (please be aware that I can't use "Palm" in the name due to Palm Computing's enforcement of that trademark). The sync client software is configured with the URL of a locator service. When the user initiates a sync, it first retrieves the user name and ID from the device and sends it to the locator service. The locator service returns a URL for the root of that user's dezkset. The nice thing is that the locator service can be anyting you want. In my case while I'm still writing and testing the software, I just have a simple DTML Method that returns a text/plain document with the hardcoded URL of my dezkset. However, you can do anything you want here. Use the ID or name to index into a SQL table with Z SQL Methods. Use the Zope LDAP support that is being talked about. Whatever -- you can do anything you want. The locator service doesn't even have to be on the same machine as the dezksets, so you can just have a plain CGI service somewhere else, if you want. Ideally, each person at an organization runs the client on their desktop. Because of the locator service, anyone can sync their device using anyone's cradle, and it will sync to the appropriate dezkset. There could even be "public" cradles available. You can also sync over the Internet from anywhere in the world. Once the dezkset is located, the client runs sync conduits as necessary, speaking HTTP to the dezkset to obtain the necessary information. The information is returned in XML format. The dezkset consists of the following objects: Palm File - subclass of File that knows a little bit about the internals of .PDB/.PRC files and can display various header information. For resource files, it'll show you a little table of all the resources. Dezkset - foldoid representing a user's palm desktop. Acts like a regular folder, but retains order information (to decide in which order to run conduits) and allows conduitish objects to be enabled/disabled. TimeSync - conduit object. Used to sync the device's clock to the time on the sync client system. The user can pick the schedule on which to sync the clock (Every Sync/Daily/Weekly/Monthly). Backup - Foldoid conduit. User selects schedule (every n syncs/days/weeks) and options (full or incremental backup, and wether to backup only stuff that asks for it, or ignore the backup bit and back up everything). Backed up files are stored as Palm Files in the folder. You can have more than one -- I have an Incremental backup every sync, and a Full/Ignore Backup Bit backup every week. Installer - Foldoid conduit. Put any Palm Files in this folder, and on sync they will be installed to the device and deleted from the folder. Memo Pad - in progress. I have generic mixin support (both for the sync client and Dezkset) for syncronizing categories between the palm and dezkset, which works. I'm still writing the management interface for memos. The goal is to have Memo Pad be a foldoid that takes any Zope object, plus special Palm Memo and DTML Memo objects. Palm Memos are regular memos that will be synced bidirectionally. DTML Memos will be special: they'll always be considered modified, and will always override the matching memo on the Palm. Unlike regular memos that contain plain text, DTML Memos contain (surprise!) DTML which is rendered to produce the final text that will be put on the palm device. So, you can write an external method that fetches the latest weather forcast, and have a DTML Memo that calls it. Then every time you sync, you get the latest weather. Or, use the contributed slashdot-fetcher product to get the latest headlines. Whatever, the choices are limitless. (This by the way is why the MemoPad can contain any Zope object -- convenience so you can group any external methods or other objects used for DTML Memos together in one place). I'm thinking now that I may split it, sort of like Confera, so that the generic zope objects and Memo contents are separate. ToDo and AddressBook - once the generic sync support for Memos is done, these will be fairly straightforward. The hardest part will be the zope management interface (which is not terribly hard). I'm going to do vCard support of some kind for AddressBook. It'd also be nice to have "replicator" addressbook entries that get theirinformation from another source periodically, so selected entries in you adressbook can be kept in sync with a company employee database, for example. DateBook - Similar to the above, but the sync logic has a few extra complications (conflicting appointments). Some clever person already wrote a calendar display tag that will make the management interface easy :-) I'd like to support vCalendar and/or iCalendar stuff.
On 22 Jul 99, at 15:40, Ty Sarna wrote:
One I came up with is something I needed anyway, a good "desktop" for the Palm Computing Platform. pilot-link is very, very basic. KPilot is not very extensible. But a Zope-based desktop has some interesting benefits. First, it's easy to extend. Second, it's a GUI appliction (albeit not with the slickest possible interface, due to the limitations of html), without introducing the problems of portability or all the labor required for a traditional GUI. Third, it means not only can you take your data on the road in the pilot, but you can also access it on the road via a web browser. Fourth, you can sync over the web, if you have appropriate client software and a cradle on the local end.
Ty, I need to do the same thing for Windows CE. Do you think it'd be wortwhile to "genericize" the zope backend (ToDo, Address, Calendar, Backup, Memopad) such that both Palm and Windows CE devices could use it? In fact ... I think part of your existing conduit code would also work for Windows CE. This could be mighty interesting -- backup either Wince or Palm to the same Dezkset ... or, be able to pass data between these two types of devices via sync. Wince devices could sync either via their desktop, or directly to the Zope server (if the CE device had a native sync program) -- I'm mostly a Windows CE developer, but I do have all the palm tools as well. Can we talk? -Brad Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
In article <199907221602.MAA01970@anvil.murkworks.com>, Brad Clements <bkc@murkworks.com> wrote:
I need to do the same thing for Windows CE.
Do you think it'd be wortwhile to "genericize" the zope backend (ToDo, Address, Calendar, Backup, Memopad) such that both Palm and Windows CE devices could use it?
I don't know. Possibly. It depends rather a lot on the internal data format of ToDo, Address, etc on CE, which I don't know anything about. Even if they're similar in outward appearance, it's possible that the internals are different enough to make supporting both hard. I'm certainly interesting in finding out, though!
Can we talk?
Sure. I'm not going to be able to work on this stuff again for a month or two probably, though...
On 27 Jul 99, at 17:07, Ty Sarna wrote:
Do you think it'd be wortwhile to "genericize" the zope backend (ToDo, Address, Calendar, Backup, Memopad) such that both Palm and Windows CE devices could use it?
I don't know. Possibly. It depends rather a lot on the internal data format of ToDo, Address, etc on CE, which I don't know anything about. Even if they're similar in outward appearance, it's possible that the internals are different enough to make supporting both hard. I'm certainly interesting in finding out, though!
I think that vCard would resolve address and calendar stuff. Perhaps a "toDo" could be stored as a specially formatted vCard calendar entry.. ?
Can we talk?
Sure. I'm not going to be able to work on this stuff again for a month or two probably, though...
Thats ok, kind of fits my timeline too. -B Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
This is really good news. At the moment, I go through a *lot* of hoops to get my study guides into an XML format (from RTF) and then into SQL so that they can be delivered through a Zope frontend in good old HTML. An example of what we do is at http://nle.ncl.ac.uk/nle/demo/ (select the 'database driven study-guides' link) One thing that we want to be able to do is edit the material online - however, to do that means that we need to recreate the XML element, together with it's attributes from the SQL entry, and then put it in the right place in the XML document hierarchy. Then go through the conversion process again. If I can put my XML documents more or less 'as-is' into a Zope system, I am going to be one *very* happy camper! Tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
I thought you'd like this one Tone, ;) ----- Original Message ----- From: Tony McDonald <tony.mcdonald@ncl.ac.uk> To: Zope List <zope@zope.org> Sent: Wednesday, July 21, 1999 9:45 AM Subject: Re: [Zope] ANNOUNCE: Zope/XML Roadmap
This is really good news. At the moment, I go through a *lot* of hoops to get my study guides into an XML format (from RTF) and then into SQL so that they can be delivered through a Zope frontend in good old HTML. An example of what we do is at http://nle.ncl.ac.uk/nle/demo/ (select the 'database driven study-guides' link)
One thing that we want to be able to do is edit the material online - however, to do that means that we need to recreate the XML element, together with it's attributes from the SQL entry, and then put it in the right place in the XML document hierarchy. Then go through the conversion process again. If I can put my XML documents more or less 'as-is' into a Zope system, I am going to be one *very* happy camper!
Tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
participants (8)
-
Amos Latteier -
Amos Latteier -
Brad Clements -
Martijn Faassen -
Martijn Pieters -
Phil Harris -
Tony McDonald -
tsarna＠endicor.com