[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Groves, IsNess and the Generic Data Object. [was.. Another try on Gr
Graham, Thanks for this post. I think this is a useful discussion... [Graham Moore] >I saw the following from Sean > >>>I believe it makes perfect sense to *think* of MPEGS, PDFs, >>> whatever, in XML terms. > >This is NOT what groves are about. Groves are about thinking about the >'IsNess' of things. > >XML is one thing you could get as a serialisation of a grove model. > >Consider.. > >root node >| >----- named prop 1 - type node > | > ----- named prop 2 - type basic > | > | > ----- named prop 3 - type basic >| >| >----- named prop 4 - type node > | > ----- named prop 5- type basic > | > | > ----- named prop 6 - type basic > > >Above is the abstract data model for a thing. It could be any thing. There >is NO XML I have >just captured the 'IsNess' the first class properties of the thing. I have >not thought about XML I have thought about the properties of the thing. In the above you have done what any intelligent, carbon based life form known to man would have done -- you have structured a domain model into a *hierarchy* of objects. I look at your diagram and in my head I see nodes called "named prop 1" and "named prop 4". I see other nodes that are contained within these nodes called "named prop 2" and so on. That level of abstraction -- nodes -- is all I need to process this data -- given some simple API. XML provides such a simple API. I need to simply mentally map the nodes and arcs into XML terminology of elements and attributes. This done, I can write software apace using SAX, DOM or any other XML API. Lets pretend the above data is in a data format known as FOO and accessible in CORBA land via a FOO-API. You seem to be asserting that I need a "grove" for this because the property set mechanism of the grove paradigm allows me to work in terms of an object API rather than an XML API. In other words this: # Access instance variable "named prop 5" # of object "named prop 4" named prop 4.named prop 5 instead of this: <named_prop_4 named_prop_5 = "..."> (or its equivalent (ontological arguments aside)) <named_prop_4> <named_prop_5>...</named_prop_5> </named_prop_4> I don't buy it. I personally do not find the prospect of programming the latter rather than the former in any way daunting or limiting. It is a trivial transformation to take a hierarchy of typed nodes and associated attributes and create an object hierarchy if I really want to be able to use "object.instance attribute" syntax. > >Now, if I decided that I need a serialisation of my grove then I need >to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition >provides us with the >canonical representation for doing such a thing. > >Obviously the canonical representation is defined in terms of an SGML DTD >and thus I could >create XML and SGML instances for my grove model. Equally though I could >serialise the model as >an S-Expression. > Agreed. >I think the point is that the grove paradigm should not get people to think >in terms of XML >but in terms of better appreciation of the properties of the notations they >are dealing with. This is where I think you have misunderstood my position. As human beings we have a cognitive pre-disposition to thinking in terms of hierarchies. There are many, many ways to represent such hierarchies syntactically - C++ programs, SGML, S-Expressions, tortuously inter-linked relational database tables, CODASYL, STEP and of course XML. They are all basically syntactic sugar. The hierarchy exists independently of any syntactic form used to give it a digital rather than cognitive form. XML has a nice simple syntactic representation for hierarchies. It uses certainly terminology to do that - elements and attributes. This terminology leads naturally to an API for hierarchies that uses terms like: startElement attributeList and so on. This API is all you need to process arbitrary hierachies of data. It is *not* a pre-condition of programming to this API that the data must have been previously serialized in XML notation! Earlier in talking about "IsNess" you say: >There is NO XML This is exactly my point! XML is syntax for representing a hierarchy. This syntax leads naturally to an API that is couched in terms of elements/attributes. This API is the key. You do not *need* to serialize data to XML syntax in order to use this API. > >I agree that the concept that groves can be seen as a way to add tags to >untaggable data as >very powerful. But the more general case is that the grove paradigm gives >names and first >classness to otherwise unaddressable properties. > I see it as a trivial transformation to convert a hierarcy of elements and attributes into a collection of objects with associated instance variables. I believe this has been done on numerous occasions in the SGML world. I think it was Bob duCharme who wrote a paper about transforming SGML instances into object hierarcies using Smalltalk as the implementation language. Some time ago, I prototyped an algorithm to do it in Python but I never got around to implementing it because I never saw the benefit of it for my work. Having said that, I do not work with STEP or CAD system data where I guess such a model transformation would be more useful. [...] >It is the concrete focus that I want to start with, > >The most striking difference between XML and a Grove Model is that in the >domain of 'cars' an Grove will let you access the value of the 'door' >property, the grove for the XML representation of the car will let you >access an 'attribute' of an element that is a serialisation of the object >'door'. As Paul said, Groves remove a level of redundant indirection. But this transformation is trivial! I guess I am having difficult seeing why I need to employ the vast edifice of abstraction that is the "grove paradigm" in order to do this. Somewhere along the line someone seems to have had an "Aha!" moment which went like this "...ergo we need groves". It is the "..." bit that I do not see. regards, <Sean uri="http://www.digitome.com/sean.html"> Developers Day co-Chair WWW9, April 2000, Amsterdam <uri>http://www.www9.org</uri> </Sean> 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
|