January 1999 - Zope - Zope lists

Re: [Zope] - Documentproperties - XML/RDF
by Wiebe Kunst 08 Jan '99

08 Jan '99

>Jim Fulton wrote: > >First, the short answer is that supporting RDF >is clearly the right thing to do. I'm not sure exactly >when this will happen, although I can assure you that >progress will be evolutionary. > Great !!! >OK, then here are some initial observations/ramblings. > >- There is an emerging notion of "content", as opposed > to "method" objects. Content objects are meant to contain > information to be published. Methods OTOH are intended > to be used to publish content but are not content themselves. > Yes and No The concept of documentmethods is very powerfull and I don't think one should do anything to cripple this concept. But I think that RDF can be a very powerfull extension in terms of attributes (not content). I like to view the documentobject as a pointer to content and methods for dynamicly creating presentations of content. However RDF elements (attributes) can extend the documentobject with meta-data, which is extremly important in applicatons for information-retrieval. > I expect that most "content" objects will allow > more or less arbitrary properties. This can be true if the documentobject entirely should implement the XML and DOM architecture, which probaly is much more complicated (?) since it probally rocks the whole objectmodel in Zope. >- There should be a way to generate RDF text from content objects. > In fact, there should probably be ways to generate RDF for any > object and for various collections of objects. When we're talking about meta-data that is. And yes that would be very nice. > I assume that there are one or more reasonable mappings from > the Python and Zope Object models to the RDF object model. > Such a comprehensive effort is beyond my current bandwidth. :) I think you guys are doing a tremendous job already, but of course one always begs for more. :) >- I propose to add a standard method for getting an RDF text from > objects. I'm open to name suggestions for this method. > > For example, assume there is a method named ZRDF. You could > get a RDF text for an object, a/b/c with a URL like > a/b/c/ZRFD. > > You could also arrange to have the RDF embedded in rendered > content. If a/b/c is a DTML Document (content) then > you could have the head be something like: > > <head> > ... >  > </head> > ... Embedding RDF-data in the head-tag is not considered "good practice", but as long as not all browers support XML-RDF we really should have this option. >- There needs to be a way to define schemas (namespaces) for properties. > There are a couple of issues here: > > o We need to be able to define schemas for properties. I don't think so. According to the RDF specification schema's er referred to in the RDF. A schema is just a textfile, like the one attached (for the Dublin Core). So, I think we need an RDF (python)object which dynamically configures itself according to a schema. > o We have to be willing to allow multiple properties with the > same name, but different schemas. Alternatively, we need > to be able to define distinct schema sub-objects that act like > property "sheets". Hm. Maybe this is the right way to go. > Maybe you can walk up to a content object and add a property > sheet in which you specify a schema and the associated property > values. This new property sheet then becomes an additional > object view (accessed via a tab). Yeah, like the propertysheet for folders. > From Python, properties in property sheets would be accessed > through the property sheets. For example, suppose we had a document, > D. Assume we've defined a property sheet, dc (for Dublin Core). > To get the title defined by the dublin core, we'd use the > expression: > > D.dc.title > > Note that property sheets might acquire. So, in the example above, > if a value wasn't provided for title in dc, the standard Zope > title would be acquired, perhaps after checking that the value was > consistent with the dc schema. Isn't it easier to let DTML take care of that? > Maybe property sheets would have ZRDF methods to allow getting RDF > for just one schema. > > o Maybe there should be a way to say that a single property > value (e.g. title) should belong to multiple schemas/namespaces. > > This could be accomplished through acquisition, as described above. > > >- For content objects, it seems reasonable that some extra > effort should be made to support a standard simple meta-data > schema, such as the Dublin core. I'm not sure how > this should be accomplished in the user interface and I'm > open to suggestions. For example: > > - Should there me a way of saying: "I want all of the > Dublin Core Properties"? In the system I'm designing I want a systemadministrator to make such decisions and not the individual user. > - Is it enough to allow any properties to be defined and > leave it up to the user to decide which properties > should be defined? > > - To what degree should properties be tied to specific > schemas? How should users define or reference schemas? > Should Zope have a tool that lets someone type in a URI > for a schema and adds the associated properties to an > object? Should there be RDF Schema objects in Zope > that should support managing proport schemas? > > - Should there be schema-dependent property views? > (Probably yes. See above.) See above >Hope these ramblings are helpful. Comments are welcomed. > >Jim Thanks a lot sofar Jim, and I hope my comments will be of use. Wiebe Kunst

2 1

- editing with Composer hoses ZopeHTTPServer
by John Mitchell 08 Jan '99

08 Jan '99

I've just started playing with Zope. It rocks, but I've found a bug. When I edited and published a doc with Netscape Composer, the webserver locked up -- hitting anything on the server would just spin. - using default serve.py (wo_pcgi) as a webserver - access file shows a PUT command as it should - after a restart, management interface shows the doc was uploaded, but it's now type = application/octet-data (as opposed to text/html), and it's 0 bytes long. - from the Composer site, document looks like it was uploaded correctly. Any ideas? I'd *love* to show off Zope plus Composer to the higher-ups, but right now it would be .. inadvisable :) - j (using Zope Beta 2, Python 1.5.1 on a SGI, Irix 6.4)

2 1

- Mail List test Again!
by Robert O'Connor 08 Jan '99

08 Jan '99

I have not yet seen any messages posted to this list since Jan 6th nor has zope-admin responded. I look forward to participating on the list. -Bob -----Original Message----- From: Robert O'Connor <bob(a)rocnet.com> To: Amos Latteier <amos(a)aracnet.com>; zope-admin(a)zope.org <zope-admin(a)zope.org> Date: Thursday, January 07, 1999 1:42 PM Subject: Re: [Zope] - A test. No messages yet >Hi Amos & zope-admin, > >Thanks for replying. Still no messages yet to my >e-mail address (yours was the first) : I did get the >automated reply to my "options" request: > >>>>> options >ack: off >digest: off >hide: off >nomail: off >norcv: off >plain: off > >I also noted that my message was automatically >cross posted on web based egroups.com/list/zope >I joined egroups and tried to reply to my own message and it >has yet to appear. egroups seems slow and occasionally >I've gotten a "try later" server message. > >I'm looking forward to participation on the ZOPE list. >and prefer the e-mail option vs the web option. > >-bobo 'Connor ;-) > >-----Original Message----- >From: Amos Latteier <amos(a)aracnet.com> >To: Robert O'Connor <bob(a)rocnet.com> >Date: Thursday, January 07, 1999 11:56 AM >Subject: Re: [Zope] - A test. Delete me > > >>At 08:21 AM 1/7/99 -0500, you wrote: >>>Checking to see if list is active. >>>I subscribed yesterday and no messages >>>seen yet. >> >>Your subscription seems correct. Are you still not receiving any message? >> >>BTW, if you have concerns about list administration issues, please send >>them to zope-admin(a)zope.org, not to the list. >> >>Thanks, and welcome to Zope! >> >>-Amos >>

1 0

- Welcome aboard...
by Rob Page 08 Jan '99

08 Jan '99

I'd like to formally welcome two new and talented people to the Digital Creations team!! Both Ken Manheimer and Michel Pelletier are joining us. There are two M. Pelletier's in the Zope community -- Michel's "old" email address was: mike(a)icebox.dlogue.net lest there be any confusion! :) The other one is still (currently) on the loose :^). They can be reached at the following email addresses: klm(a)digicool.com michel(a)digicool.com --Rob -- Rob Page V: 540 371 6909 Digital Creations http://www.digicool.com -- Rob Page V: 540 371 6909 Digital Creations http://www.digicool.com

1 0

- ANNOUNCE: ZTemplates component release
by Amos Latteier 08 Jan '99

08 Jan '99

Hello Zopesters: Now you can download ZTemplates without bothering with the entire Zope release: http://www.zope.org/Download/ZTemplates This release does not contain any changes from the current Zope release of ZTemplates. This component release brings you your old text-generating favorite the DocumentTemplate package without all that other newfangled stuff that you're not interested in. I don't anticipate any more separate Zope component releases soon. Let me know if you find these component releases useful at all. Have fun. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

1 0

- Hints and strategical info for database migration needed (longish ) )
by Stefan Franke 08 Jan '99

08 Jan '99

After some days of evaluation I decided that Zope is (surprise!-) exactly what I need for my current application. I'm trying to publish some thousand elements of strictly hierarchical data with an advanced search interface (for the user) and a management interface for which Zope's standard interface would be just fine. Currently I generate my data strucure - an attributed tree with cyclic links back from each element to its father - with a python program from a flat file. I'm a bit uncertain about the best way to migrate this structure into Zope and would appreciate some opinions about it. Since I would like to recycle Zope's management interface, I it seems better to have the data element-wise included into the persistent storage with a separate product class for each node or leaf type in my structure (the tree itself is very heterogenous) than to write an interface to my existing data management (not speaking of the other benefits BoboPOS provides). The questions I'm concerned about are - The performance of the query functions: At the moment, the whole data fits well into memory (few thousand elements / ~10 MB). How big is the overhead in speed and size if I turn each element into a persistent product instance. - Are Products the right way to go? - Are there any problems with the inherent cyclic structure of the data in conjunction with the persistent storage? - Let's say I would subclass Zope's folder class for my inner nodes. I think the links to the containing objects are provided anyway due to the aquisition structure? - And most important: How do migrate my data into the Z database? It would be cool for me using a HTTP file upload to completely replace the interned database with the data from the uploaded file (I could retain my existing flat file parser). But how do I access the persistent storage from (let's say) the external method performing the upload). Of course, I have seen the BoboPOS docs, but what are the concrete instances I can access from an external method? Though being generally a little bit overwhelmed by the whole Z documentation and confused by the Bobo/Principia legacy naming, the latter is one of the most unclear parts for a newbie like me: What is the surrounding API in a published module. What functions/modules/globals can I access? Any help appreciated - Stefan

3 2

- Newbie questions
by Konrad Hinsen 08 Jan '99

08 Jan '99

I just downloaded and installed Zope, and I am impressed to see how easy that is, even under AIX. So the only remaining problem is doing something useful with it... I am interested in Zope for a specific application, and before I invest lots of time in learning how to use Zope, I'd like to ask the experts whether my project is doable at all with Zope in its current version. My application is an collaborative dictionary project (real-life dictionary, not the Python data type!). The dictionary would be a set of "concepts", each of which would have a definition and any number of terms in various languages, plus any number of labels that indicate categories. Any entry (term or definition) can have any number of comments attached to it. A small number of people would be authorized to change entries (using a special password), but anyone would be allowed to add comments. So far this looks perfectly doable, although I don't know yet how. But there are two further features that are important: 1) The dictionary will be multilingual; terms, definitions, and comments must be stored as Unicode strings (or any other internal format that is sufficiently flexible). For display and entry, they must be converted to and from an ASCII representation, and users must be able to choose between several possible representations. 2) The current version dictionary must be available for download as an XML file corresponding to a specific DTD. I don't mind if it takes some Python coding to get this to work, on the contrar y :-) But I'd like to know whether this is doable at all without rewriting 90% of Zope from scratch. I am also interested in any pointers to similar projects, particularly useful sections of the manual, etc. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------

1 0

RE: [Zope] - Virtual Hosts
by Paul Everitt 08 Jan '99

08 Jan '99

Jonathan wrote: > Does Zope support virtual hosts? If so, which way works best? > I tried faking > the root via the CGI call (via Zope.cgi/MYHOST/$1) which > would work except > Zope insists on putting a "base href" header in the output > file (for what > reason I cannot say) and this tends to hose it up. I'm using virtual hosts with Apache 1.3.3 on our website. Each virtual hosts section points to a different installation of Zope, though. Is your goal to allow different virtual hosts to point into different folders inside *one* Zope installation? If so, I suggest making a feature request in the Collector: http://www.zope.org/Collector/ This is certainly a reasonable requirement. If you have some ideas on how the knobs should be presented to the administrator, let us know that as well. --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909

2 1

- re: ZSolidDA name error? additional info
by BScherer＠mobile.bam.com 08 Jan '99

08 Jan '99

As usual, I spoke too soon. I clicked on the Browse tab of the DA details page and got a 'Sorry, an error occured'. The source of this reveals: ---------------------------------------------------------- Traceback (innermost last): File /usr/local/src/Zope-1.9.0-src/lib/python/ZPublisher/Publish.py, line 870, in publish_module File /usr/local/src/Zope-1.9.0-src/lib/python/ZPublisher/Publish.py, line 583, in publish (Info: /zopeland/Solid_database_connection/manage_browse) File /usr/local/src/Zope-1.9.0-src/lib/python/Globals.py, line 234, in __call__ (Object: manage_browse) File /usr/local/src/Zope-1.9.0-src/lib/python/DocumentTemplate/DT_String.py, line 514, in __call__ (Object: manage_browse) File /usr/local/src/Zope-1.9.0-src/lib/python/TreeDisplay/TreeTag.py, line 166, in render (Object: a tree tag) File /usr/local/src/Zope-1.9.0-src/lib/python/TreeDisplay/TreeTag.py, line 256, in tpRender (Object: RoleManager) File /usr/local/src/Zope-1.9.0-src/lib/python/TreeDisplay/TreeTag.py, line 493, in tpRenderTABLE (Object: RoleManager) (Info: ([85, []], {'childless_decoration': '', 'id': 'tpId', 'branches': 'tpValues', 'header': 'info', 'url': 'tpURL'}, ([85, []],), ([85, []],))) File /usr/local/src/Zope-1.9.0-src/lib/python/TreeDisplay/TreeTag.py, line 310, in tpRenderTABLE (Object: ACTIVITY_CODES) File lib/python/Products/ZSolidDA/DABase.py, line 183, in tpValues (Object: ACTIVITY_CODES) File lib/python/Products/ZSolidDA/db.py, line 293, in columns NameError: error --------------------------------------------------------- The relevant code is: --------------------------------------------------------- def columns(self, table_name): stmt=self.stmt try: self._apply(SQLExecDirect, (stmt, 'select * from %s where 1=2' % table_name)) 293 --> except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) --------------------------------------------------------- So, error is not defined at this point. Removing it and leaving v shows that v is not defined here either. I have an idea what these should be, but I'm certain there's a Zopitista(o) out there that knows for sure.. Thanks Bill

2 1

Re: [Zope] - Documentproperties - XML/RDF
by Jim Fulton 08 Jan '99

08 Jan '99

Wiebe Kunst wrote: > > Yes - thats exactly what I would like to achieve. > > From: Jim Fulton <jim(a)digicool.com> > > > >Let me try to express my understanding of your question by > >restating your question a bit. > > > > You want to maintain the properties defined in the Dublin Core > > for Documents. That is, you want a Zope web interface for > > entering/editing these property values. > > > > Further, you'd like to be able to generate RDF formatted text > > for these properties. > > > >Am I on the right track? First, the short answer is that supporting RDF is clearly the right thing to do. I'm not sure exactly when this will happen, although I can assure you that progress will be evolutionary. OK, then here are some initial observations/ramblings. - There is an emerging notion of "content", as opposed to "method" objects. Content objects are meant to contain information to be published. Methods OTOH are intended to be used to publish content but are not content themselves. I expect that most "content" objects will allow more or less arbitrary properties. - There should be a way to generate RDF text from content objects. In fact, there should probably be ways to generate RDF for any object and for various collections of objects. I assume that there are one or more reasonable mappings from the Python and Zope Object models to the RDF object model. Such a comprehensive effort is beyond my current bandwidth. :) - I propose to add a standard method for getting an RDF text from objects. I'm open to name suggestions for this method. For example, assume there is a method named ZRDF. You could get a RDF text for an object, a/b/c with a URL like a/b/c/ZRFD. You could also arrange to have the RDF embedded in rendered content. If a/b/c is a DTML Document (content) then you could have the head be something like: <head> ...  </head> ... - There needs to be a way to define schemas (namespaces) for properties. There are a couple of issues here: o We need to be able to define schemas for properties. o We have to be willing to allow multiple properties with the same name, but different schemas. Alternatively, we need to be able to define distinct schema sub-objects that act like property "sheets". Hm. Maybe this is the right way to go. Maybe you can walk up to a content object and add a property sheet in which you specify a schema and the associated property values. This new property sheet then becomes an additional object view (accessed via a tab). From Python, properties in property sheets would be accessed through the property sheets. For example, suppose we had a document, D. Assume we've defined a property sheet, dc (for Dublin Core). To get the title defined by the dublin core, we'd use the expression: D.dc.title Note that property sheets might acquire. So, in the example above, if a value wasn't provided for title in dc, the standard Zope title would be acquired, perhaps after checking that the value was consistent with the dc schema. Maybe property sheets would have ZRDF methods to allow getting RDF for just one schema. o Maybe there should be a way to say that a single property value (e.g. title) should belong to multiple schemas/namespaces. This could be accomplished through acquisition, as described above. - For content objects, it seems reasonable that some extra effort should be made to support a standard simple meta-data schema, such as the Dublin core. I'm not sure how this should be accomplished in the user interface and I'm open to suggestions. For example: - Should there me a way of saying: "I want all of the Dublin Core Properties"? - Is it enough to allow any properties to be defined and leave it up to the user to decide which properties should be defined? - To what degree should properties be tied to specific schemas? How should users define or reference schemas? Should Zope have a tool that lets someone type in a URI for a schema and adds the associated properties to an object? Should there be RDF Schema objects in Zope that should support managing proport schemas? - Should there be schema-dependent property views? (Probably yes. See above.) Hope these ramblings are helpful. Comments are welcomed. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0