[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
I have a ramble that I constructed the other day and some additional comments about other postings. Comments: --------------------- ************************* --------------------------------- 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. 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. 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. 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. --------------------- ************************* --------------------------------- Domain: how about www.grove-paradigm.com In essense there is more to the grove paradigm than just the model, e.g. the notation processor that constructs the model, the property set defintion, the grove plan, application conformance, suggested API's. --------------------- ************************* --------------------------------- Ramble: I think paul should be applauded for making groves more accesible in his last few mails. I wanted with this mail to re-iterate some of what Paul said and add what I feel is the essence of the grove paradigm. In addition I wanted to present the Generic Data Object concept and its role in the grove paradigm. I also wanted to give some concrete explanation and focus as to the power of the grove paradigm. 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. Why did I give the above example? I feel that this is such a **fundamental** concept that it is worth exemplifying as much as possible. Secondly I need it to lead on to the essence of of the grove paradigm and the power it brings. Object Oriented development is now established, we identify our entities, they have properties and we implement them using our favourite OO langauge. Now it happens that most peoples favourite OO lanaguge is not a dynamic beast such as Scheme, Python or CLOS but a strongly typed langauage such as Java or C++, there is nothing wrong with this. We construct these classes for specific roles - see UML and the fact that classes are assigned roles within a system. We value this as it gives us robust design, better error handling etc etc. Now, what if we still had some of the rigour of the typed system but one that could be dynamic and applicable to a variety of applications. Very nice but how does this apply to the grove paradigm. 1) When you build a grove model it adheres to a property set this is in effect equivalent to a set of UML class definitions. So this gives us our rigour. 2) When you build a grove model it is typically constructed in memory as an object model. This model is constructed by a 'Notation Processor'. A Notation processor is aware of the property set and is also aware of a Notation or number of Notations. A Notation is a ***'thing'***. This thing could be a Network, a Car, a Document, An application, a person, any given data notation. Thus given a networks property set and given a network instance a Notation processor can construct a Grove Model that allows access to all the properties of the network as first class objects. Before we come onto first classness and isness how can we build these heterogenous object models. As was pointed out in a previous mail heterogeneous collections play a big role in computing. The grove paradigm perceives that Objects are just containers with a generic collection of key, value pairs. The grove paradigm works at a fundamental level of computing, values associated with names. This is achieved by having the Generic Data Object. The GDO has closure in that it always returns a value which could be another GDO, it is dynamic as new values can always be added. These properties ensure that no matter what the notation is a notation processor can create a grove model that can contain the named property values of that notation. The Power of Groves.... The value of OO is in having something, an entity, that is malable, touchable, something that can be manipulated. Many systems are not empowered as they do not have their assets, their properties as first class objects. The grove paradigm provides the ability to make everything first class. e.g. the thread on the bolt on the door of a car becomes a node - a malable object - within the grove paradigm. Now, in the world of groves we only ever have nodes and properties thus if we have 1000 notations that have notation processors for them then we have a abstract data model for *all* these notations. We can interchange these nodes at the abstract level, we can link bewteen nodes at an abstract level without needing to know about the details of the underlying notation. I can link from my thread on the bolt on the car to the procedure of screwing on the nut in a technical manual. Note - that the thread on the bolt IS the thread on the bolt not a *document* about the thread on the bolt. Why the confusion with Groves and XML It appears that the dynamism and extensibility of XML and Groves provides a good match. The thing to remember is that the Property set for every XML document is the same. I never have the property 'colour' on a grove node for an XML document I only ever have 'attribute', 'name', 'value', 'gi' e.g. given this XML doc <doc> <car colour="red"/> </doc> I can only say if I have a grove of the XML doc print node.attribute.name colur print node.attribute.value red Now, if I have a grove that represents the object car I can say print node.colour red The general grove model provide *IsNess* you talk about the thing as it IS, you talk about something in terms of the properties that help form its instance identity [identity obviously exists beyond the properties and their value]. The IsNess of an XML document is about attributes, elements and their values. The IsNess of a car is parts, colour, engine power etc. Summary The grove model enables a level abstract playing field in which to bring all notations - things. This is possible through the use of Generic Data Objects and their inherent dynamism and closure property. The grove paradigm helps us understand the essence of a notation so that we may manipulate *any* aspect of it. Kind Regards, Graham. *------------------------------------------ * Graham Moore * Consultant STEP-DPSL * gdm@s... *------------------------------------------ ________________________________________________________________________________ This message has been checked for all known viruses by the Star Screening System http://academy.star.co.uk/public/virustats.htm 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
|