What would be nice, perhaps is a new product: 'bigXML' is a folderish object
containing 1..n ParsedXML objects, and acts as a proxy component that uses
each ParsedXML instance to store DocumentFragments, as delineated by rules
written as a bunch of properties in that folder that constitute rules for
what gets stored where (perhaps expressed using XPath as a notation).
This would allow for use of the existing ParsedXML framework, and allow
improvements made to it to trickle into any product that proxied it. I know
there is only so many degrees of 'proxying' that we should do, but this
seems like a simple enough approach to get the job done? It would allow any
document adminstrator that could write XPath to manage how branches are
stored, which means they can control how the XML is optimized for their
particular use case.
Sean
-----Original Message-----
From: Jay, Dylan [mailto:djay@avaya.com]
Sent: Sunday, October 21, 2001 4:31 PM
To: zope-xml@zope.org
Subject: RE: [Zope-xml] ANNOUNCE: PT_XPath
> -----Original Message-----
> From: Martijn Faassen [mailto:faassen@vet.uu.nl]
> Sent: Saturday, 20 October 2001 8:55 AM
> To: delza@landry.alliances.org
> Cc: Dethe Elza; zope-xml@zope.org
> Subject: Re: [Zope-xml] ANNOUNCE: PT_XPath
>
>
> > One of the things I like about ParsedXML, btw, is its
> balance of effeciency
> > with persistence: Store one object in the ZODB, but make it
> look like an
> > entire DOM tree to the user (at least, that's how I think
> it works!).
>
> Right; the entire tree is currently persistent only as a whole, not as
> the individual objects. This has advantages, mostly I think storage
> efficiency and probably also some use efficiency. The disadvantage is
> that it doesn't scale all the way up to huge documents and its'
> probably relatively inefficient for DOM manipulations, as changes to
> the DOM cause the entire tree to be stored again in a new
> transaction..
>
> Eventually a hybrid segmented DOM approach may be the best solution.
Which is a much better idea if your treating a document as a database. Much
more efficient for heavy querying. The only problem is you need a flexible
way to represent the policy of what becomes objects and what elements are
stored as one object. Perhaps some extension DTD could mark where the
chunking occurs.
> > Part of
> > the reason I start thinking about the ZODB when we talk
> about querying for
> > objects as if they were all XML is that it would be handy
> to do even outside
> > of Zope, in other projects which use the ZODB. I would
> like to be able to use
> > ParsedXML for general XML persistence from Python, but it
> seems to be closely
> > tied to Zope.
>
> So you're thinking about a generic way to represent arbitrary Python
> objects as XML. It's an interesting idea that I need to think
> about a bit
> more. I'm talking about a higher level representation of particular
> existing Zope objects. The advantage I see in the latter is that it
> may make more sense to a human than the direct representation
> of object
> internals. An advantage of a more generic representation would be
> that you represent absolutely everything, but of course that can
> also be a weakness -- it is what makes XML .zexps rather hard to
> read.
I think this problem will be solved to some extent if the component
architecture is going to be a level between zope and the ZODB. I'm not sure
if it is or not but this would mean you could request a given ZODB object as
XML and it would happen for you. As to what the default view for unknown
object types is... it's kind of abitrary. You can't make much guarentees
about what the XML would look like for some new object type so why put
anything in at all. I prefere the <unknown> object representation.
> > I can see how a registry could be useful, but I think it
> should be used to
> > *override* some reasonable default behavior. That is, any
> Zopish object
> > should be accessible via ZDOM, and objects which have
> special needs should be
> > able to register those to override the defaults.
>
> That would be an interesting compromise, though I'm still not
> convinced
> you could actually expose the implementation details... hm,
> what about security
> issues, for instance?
A registry seems to be how the component archetecture is going to work so
I'd say that would be the way to go. Less change when the component
archecture does appear. Plus it was the advantage that no internal zope code
needs to be modified which makes this much better for distribution as a
product.
_______________________________________________
Zope-xml mailing list
Zope-xml@zope.org
http://lists.zope.org/mailman/listinfo/zope-xml