Argh! Almost had this message entirely written and the power shuts off. *sigh* Here we go a second time... Moved to zope-dev for obvious reasons. Michael Bernstein wrote:
[snip]
I think we're on the same track, see my XLink ramblings from yesterday: http://lists.zope.org/pipermail/zope/1999-November/013235.html
Hmm. thanks for the pointer, I missed it first time 'round. The XLink spec was VERY interesting reading. Mostly it seems as though it deals with how to express (render) in XML the type of non-hierarchical structures we're discussing, and provides a good source for use-case scenarios. The question remains "How do we implement this data in the ZODB and management interface?".
You're welcome. And to answer your question: In the ZODB: a specialized form of XML Document that understands what an XLink is, when a such a document is created it catalogs it's X Links in "LinkCatalog" (rather than "Catalog"). According to one of the posts on cataloging XML Documents, this should be rather easy (see http://lists.zope.org/pipermail/zope/1999-November/013240.html). Management interface: a simple form interface that creates an XML Document and manipulates it via Zope's DOM. You could even add links inline to an existing XML Document doing this. The form interface can do whatever it needs to do to be pretty (see my ramblings below on RelationshipAware). [snip]
Well, while exposing XLink-type information to the client as an excellent goal, and should certainly be taken into (very serious) consideration, I am more interested at the moment with making this type of information available to server-side applications.
Absolutely, server-side is the only practical application of XLink stuff right now. [snip]
This was the most interesting part of the XLink spec for me, in that it validated a notion percolating through my brain that objects do not neccessarily have to be aware of their incoming links at all. Implementation-wise, this means that only Classes and objects that inherited from a 'relationship-aware' base class would display the 'Relationships' tab in the management interface.
All objects could have access to the "Relationships" tab. A RelationshipAware base class could be useful to make the interface a little more convenient... like providing a subset of possible links that make sense with this object. (Though, don't take away the ability to create any kind of link you want. (As a side note, if you find the out of line links interesting, check out Xanadu at http://www.udanax.com. It's a full blown hypertext system that provides unique (possibly out of line) links that don't break when you move documents around... even across servers. At least, that's what it's supposed to be, it's not entirely complete. :) They have a lot of good ideas, though.) [snip]
Well, you're correct that the client-side applications you're thinking of do not require this sort of feature. However, for an web interface that allows you establish these relationships (ie: create XLinks) implementing an 'Object picker' that is constrained by the object's meta-type is fairly important, and should not have to be re-implemented from scratch for each application. Putting the constraints in the Relationship Object instance seems like a convenient location.
I agree that an 'object picker' is needed. I also agree that it would be convenient if the interface could give you a good set of defaults (this is where RelationshipAware comes in, as I said above). However, I can see no technical reason to restrict what kind of objects that Links can point to. [snip]
I'm not sure I understand your third question.
Let me give an example of what I mean: In the DTML of the default method for a book object that has a defined relationship called 'Author' to a 'Person' object (which has a 'FullName' string property), I would like to place a DTML snippet that said <dtml-var Author.Fullname> and have the final document render the pointed-to object's 'FullName' property, even if the 'Book' object has one as well(unlikely) or could acquire one from somewhere (possible). The chief advantage to containing 'pointers' within the objects themselves is that it makes implementing this easier (Re: http://lists.zope.org/pipermail/zope/1999-November/013215.html).
I see, you basically want a few convenience methods to abstract away the Link Catalog (a good thing, too) in DTML. Again, it seems this would be a good place to RelationshipAware to take over functionality. The base class could provide a few methods that would return a list of links based on various constraints... i.e., who's being pointed to, or what role the link has. This should be relatively easy to provide and would make it easy to iterate over the list in DTML and provide a nifty interface to the incoming links.
(BTW, please tell me if my ramblins make any sense or not, thanks. :)
Yes, you make a lot of sense, and when more browsers are XML aware, the XLink syntax will be very important for moving some of this stuff onto the client, instead of leaving it all on the server. On the other hand, this might be even more important in the interim when considered in combination with XML-RPC for moving more complex data between servers. (cue blue sky music).
More blue sky... a standard interface between servers to notify of new links. I could use XML-RPC to tell your server that my server just created a link that points to you and you update your Link Catalog is updated appropriately. Make it a standard interface, and anyone who has a application server that understands XML, XLink and XML-RPC can participate. Perhaps it's even possible to provide Xanadu like, unique, unbreakable links across servers that can be moved about willy nilly. :) I think I covered everything I lost in the power outage. I hope. :) -Otto. Addendum: something new just came out called the Schematron, see http://www.xmlhack.com/read.php?item=121 and http://www.ascc.net/xml/resource/schematron/schematron.html. It's basically a new way of validating an XML document based on XSL. This sounds like precisely the kind of thing necessary to decide whether an XML Document in the ZODB has XLinks... and possibly could be used to figure out what kind of XLinks documents belong to. Rather than provide a specialize sub class for each XML Document you want to customize the Relationships panel for, you simply provide a schema for the kinds of documents that your links link to and Zope figures out whether XML Documents it knows about fit that profile and change the management interface accordingly. (I know that's not entirely coherent, but I wrote it quickly so I can get back to reading about the Schematron. :)