[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ANN: XML and Databases article
"Didier PH Martin" <martind@n...> writes: > Hi Daniel, > > Daniel said: > ------------------------------------------------ > When faced with "groves" I still have a serious problem with both > points: > - Show me a definition so that I can understand the term and > underlying concept clearly enough that an implementation > time is spend not collecting and reading papers but implemening > something well defined. > Even reading http://www.prescod.net/groves/shorttut/ I still can't > get a clear definition of "what is a grove precisely". > Not at the concept level, but a implementable definition say > on top of the XML infoset (for XML documents). > > Didier says: > ------------------------------------------------ > I agree with you on that point. Actually groves are defined as abstract > entities and there is no common API to groves (each implementer ca define > its own interface). > I suggest also that you take a look at the PERL open source project > because they too have included a grove manager in the PERL > package. Did you noticed that PERL already implemented a Grove > module? That would be the Data::Grove (in libxml-perl) module and it's only current set of node classes, the XML::Grove module. If you'd like to look at a very simple implementation of groves, those would be the ones. In Data::Grove, ``nodes'' are Perl objects (named, or ``blessed'', hashes), node-lists are Perl arrays, and named-node-lists are un-named, or ``anonymous'', hashes. Even though nodes are ``objects'' they are still accessed directly using Perl hash syntax (i.e. there are no accessor methods). (The same could be done as easily in any language, of course.) In the current implementation of Data::Grove the grove is ``passive'' -- the view, or ``grove plan'', of the grove is fixed at the time the grove is built, there's no support for enforcing constraints, and character data does not appear normalized. This differs from other grove implementations which I would call ``active'' -- the view of the grove can be changed dynamically, constraints are checked and/or enforced, and groves always appear normalized. Grove plans were described in another message, but an example is where you could choose to see entity reference nodes in the grove or just the characters that replace the entity reference. Groves are often compared to DOM. In grove terms, DOM Level 1 presents two very specific grove plans, Core and HTML. DOM defines these grove plans in terms of accessor methods for specific properties and a fixed set of constraints. In contrast, groves act more like generic containers. The API for accessing the generic containers is left to the implementation, property and value constraints are defined seperately, and the user is allowed to choose which set of property and value constraints to use at any particular time. Simply put, the idea behind groves is to seperate the definition of properties from the API used to access those properties. -- Ken MacLeod ken@b... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|