[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Another try on groves
Imagine that you are a Mozilla programmer. One day you are trolling through the XML family of specifications and you notice that RDF and XLink offer some intriguing possibilities. RDF allows you to associate, let's say, ratings with components of XML documents. So you could have a big XML document representing a Slashdot forum and you could use RDF to hide the articles ranked as trolls. Using RDF all of this could be done on the client side using sophisticated Mozilla-built in features. Of course a decent programmer would not restrict the feature to Slashdot, or to online forums but to any XML document with ratings described by RDF. Using XLink you could also allow links to be imposed. These could point to other documents on the Web that relate to the current conversation. They could also be annotations by non-slashdot members. A light comes on. Now you understand what these specifications were meant to allow. So you start madly implementing. As you are about a third of the way through you notice that the RDF and XLink specifications do not explicitly limit their targets to XML. ANY media type with a fragment identifier can be described by RDF or linked by XLink. Uh oh. Things just got a lot more complex. You can now address into PDFs, MPEGs, ShockWaves and CorelDraw graphics. Of course Mozilla supports those formats though third party plug-ins. You don't even have the code to them...the only way to influence them is to improve the plug-in API. Now you have a choice: you can subvert the intent of the RDF and XLink specifications by pretending that they only apply to XML or you can step up to the challenge of implementing the features in a manner that does not discriminate against non-XML media types. Obviously MPEG movies are not going to be XML documents in our lifetimes. If you are in a hurry you might jump to the conclusion that the best way to address into these media types is either to convert them INTO XML (perhaps reasonable for PDF) or at least have them expose their properties as a DOM. The problem with being in a hurry is that you end up wasting time. You will waste time here because the impedence mismatch between MPEGs and the DOM is going to be huge. A frame is not an "element", it has no "attributes". Now I claim that a frame is an object and that it has properties. And any idiot knows that objects can be represented in XML using a variety of techniques but think about the logic of doing it this way: you are taking a thing that is "logically" an object, expressing it in terms of a text file format so that another module in the same process can re-interpret it as logical objects. The *only good reason* to dumb something down into XML elements and attributes is to move the information between processes separated by space, time or incompatibility. Using XML as the "universal API" is madness because there *is no universal API*. The idea is patently ridiculous. (some Unix evangelists have claimed that open/read/write is hte universal interface but actual Unix usage demonstrates that this is not even close to true...look at the heavy usage of CORBA and IDL in Unix GUIs) The term "dumb down" is not an insult against XML or the DOM. After all, the act of representing something as XML necessarily "dumbs down" the XML to Unicode characters but that can hardly be considered an insult against Unicode! Representing Unicode requires a dumbing down into octets which are dumbed down into bits to be sent across the wire. All of this dumbing down is great when it is necessary but inconvenient and inefficient when it is not. So as a Mozilla programmer your next step is to define a base class for "linkable objects". Let's call those "nodes." In order to navigate around these nodes it is useful (some claim necessary...I believe them but have not verified this for myself) to have the nodes have properties like "parent", "children", and so forth. Yes, this is very DOM like but the big difference comes in the next step: the next step is that the "properties" of these things can be rich -- not "dumbed down" to elements and attributes. This not only removes two layers of code (dumbing down and building up) it also removes a lot of potential for confusion: "the object's principle light source property is represented by a reference to a principle light source element which represents a light source object. Go read the documentation to see how a light source object is represented in our DOM representation." Why not represent a "principle light source" property with a property named "principle light source" and why not let its value be a real object (not an element) with properties that are also real objects. Okay, so what else do we need in our "node" ("linkable object") interface? Well, runtime discoverability of node types and properties is useful in any language and absolutely required if we are going to expose our objects in a dynamically typed language like Javascript or DSSSL. So we need methods that allow us to find out the node's class and property list. This base "interface" is known in grove terms as the "intrinsic properties." They aren't just magical hidden features -- they are properties just like "principle light source" and "element type name." There's an important operation we need every pair of nodes to support: given two node references we need to be able to figure out if they are to the same node. If we are going to make a list of all opinions about a particular Slashdot posting then we need to be able to recognize when multiple links are talking about the same thing. This is why I've harped in the past, on this list, about object identity. Linking is not going to work properly unless we figure it out. Arguably, object identity is the *whole point of groves*. But of course there is more. Now consider that some applications work on all XML document types but many work on only a particular document type. The same holds for COM objects. The same holds for groves. Some will work with any old grove (e.g., a hyperlink database) but a renderer will require a particular set of node types. Just as we have a schema to allow XML documents in a class to be consistent we have a schema for groves called a "property set." This can even be compiled into a header file in a strongly typed programming language (just like a COM type library or OLE class). Here are what I consider the crucial points of this discussion: * existing web technologies will not "work properly" without a data model for linkable, annotable data. These technologies implicitly depend upon this model that *does not exist*. Call it a universal data model, meta data-model, meta, meta, data-model, whatever. It needs to exist. * near-term software applications will run up against the lack of this model not in the distant future but in years or months. Arguably they have *already* run up against the problem of the lack of this model. The XML information set is a stop-gap for applications that are all XML but this is supposed to be a hypermedia web -- the stopgap can only hold for so long. * there is nothing futuristic about groves. They take some basic ideas from the information set, add them to some basic ideas from COM/CORBA, add in a few original ideas specific to the hyperlinking domain and that's it. Groves only seem abstract because most people are still confused by and scared of linking applications. The (IMHO) chaotic development of linking and annotative specifications and software on the Web is a symptom of this same problem. Paul Prescod 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
|