[Zope-dev] Re: [Zope] Pointer-to-Object Properties

[Otto]

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. :)