Cart
[Home] [By Thread] [By Date] [Recent Entries]
David Megginson wrote: > If you have a function loadXML(), you get a DOM tree or a bunch of SAX > events or something similar; if you have a function loadRDF(), you get > a collection of objects with attributes and relationships. In either > case, a schema can tell you things like "element type/class B is a > kind of element type/class A", but that's secondary information; the > primary information is "element X is an object of class Y with > identifier Z, while element A represents a relationship between this > object and object C". A schema gives you this information too. The problem of how to attach a schema to an instance is not yet resolved, but it is a purely syntactic consideration and a satisfactory solution will be found. This then tells you what class a given instance belongs too. The identity can be specified using an ID attribute; this is exactly the way it is done in RDF. That an element represents a relationship is implicit in the content model of the element. SAX is great as far as it goes, but we seem to be agreeing that an additional layer is needed on top. This layer is not the DOM. One of the lessons that I learned from my time at POET Software is that, although we had an excellent generic API, the vast majority of our customers wanted to work with real C++ (and later Java) classes in their problem domain. But there is nothing to say that a loadXML() function must return a DOM tree. There are a variety of efforts to create domain-specific objects automatically from XML objects. I don't have a list at the tips of my fingers, but if anyone does it would be a great resource. They are out there because I keep bumping into them. > If you're interested in a collection of objects in the first place, > why should you have to see or know about XML elements and attributes > at all? Or to put it a different way, why should people constantly > have to redo the work of extracting objects from XML, when they're all > trying to do the same thing? Once again, there are already tools that provide this functionality across applications (i.e. they can be plugged in and used without additional development). The interest of XML is essentially as a way to serialize objects and send them across a network, as you also stated. > I think that reasonable people can argue that RDF is not the best > solution to the problem of object exchange in XML, but I am somewhat > surprised to hear people deny that the problem even exists: there is > an enormous demand for exchanging objects in XML (businesses exchange > a lot of structured data), and it's hard work to have to figure out > over and over how to construct objects from a SAX stream or a DOM tree > especially when programmers with XML knowledge are scarce and > expensive. > > I have no doubt that we need an abstract object layer on top of XML. > Right now, RDF is the best solution currently available (XMI also has > its advocates), but I'm ready to listen about anything better. In no way do I doubt the importance of being able to exchange objects in XML, but I do have serious reservations about RDF as the way to do this, and they have nothing to do with the hairy syntax or hard-to-understand spec. What is lacking right now is an overarching approach to using XML in real-world applications. To be quite blunt it seems ashame that a lot of really great work is being put into the RDF effort (including a very valuable vocabulary for collection classes, just to name one) instead of being integrated more tightly into the overall XML architecture. This is especially so because there isn't an overall XML architecture yet, and the effort and thought that are being put into RDF could bring us a long way towards this. I don't agree with the conclusions of the Cambridge Communique. I think that if the work being done on RDF were refocused to making sure that XML Schemas do everything that the RDF advocates are rightly claiming is necessary, that we will see a clear win in terms of pushing the whole XML effort from a theoretical effort into a major paradigm shift with extensive real-world implications. As things stand, this work is being diluted because both we are asking people to read about, grasp and implement two things instead of just one. Cheers, Matthew 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 unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
