Loading ...
Sorry, an error occurred while loading the content.

Doing the Blog

Expand Messages
  • Kurt Cagle <kurt@kurtcagle.net>
    **************************** Kurt Cagle s Metaphorical Web **************************** Tuesday, December 10, 2002 http://www.kurtcagle.net kurt@kurtcagle.net
    Message 1 of 1 , Dec 10, 2002
    • 0 Attachment
      ****************************
      Kurt Cagle's
      Metaphorical Web
      ****************************
      Tuesday, December 10, 2002
      http://www.kurtcagle.net
      kurt@...
      ****************************

      ===============
      Doing the Blog
      ===============

      I've been doing an e-mail newsletter entitled The Metaphorical Web
      for about two months (see below for subscription information)
      and it has been suggested by one of my readers that I may want to
      investigate getting into the Blog scene. Given the nature of
      such writing, I figured it was probably about time, and, having read
      the works of a number of other superb Blog writers, figured
      it was worth exploring. Hence, I want to welcome you, gentle readers,
      to the thoughts and commentary of Kurt Cagle on all things
      webbish and metaphorical, with, of course, an emphasis on XML based
      technologies. This blog will likely complement (and
      occasionally duplicate) my newsletter, but I may choose to do one
      route or the other if I feel the mood to do so.


      I have a few comments on the medium itself. I'm using blogger.com,
      which has a basic web interface for entering and editing text.
      The notion of a blog as a publishing vehicle is one that has
      fascinated me for some time; despite the fact that I do run my own
      web sites, the amount of work necessary to post new content, create
      associated links and potential RSS files and disseminate that
      information makes it difficult to keep such sites even remotely
      current. Email is better, in some respects - you can form a
      reasonable idea about how many people you are reaching and get a
      certain degree of feedback on your work, but email suffers from
      the fact that the people receiving it have to initiate the process,
      meaning that you are unlikely to pick up the casual reader or
      websurfer in this manner. That's one of the reasons that I see the
      combination of e-mail and blog to be such a potent combination
      - it makes asynchronous communications possible while still providing
      the benefits of easy publishability. It's no wonder that
      it's become such a quickly expanding medium.


      At any rate, this is an experiment. Feel free to comment to me about
      it at kurt@..., and if you have some topics you'd
      like to see explored (or problems answered, or at least answers
      attempted) by all means let me know. For those of you who are
      already on my e-mail list, my blog can be found at
      http://blog.kurtcagle.net

      ===============
      XML Likes MVC!
      ===============

      I've been working on projects recently for several clients that have
      got me to thinking about the Model/View/Controller (MVC)
      architecture and the fact that XML seems to be so aptly suited for
      this particular design pattern. MVC emerged first in the
      context of SmallTalk as a way of creating applications that utilized
      extremely loose coupling, and is one of those design patterns
      that is typically taught in computer courses and then consequently
      forgotten. I think one reason for this is the fact that most of
      the programming that is done today involves the use of visual IDEs
      that make it extraordinarily easy to violate MVC principles,
      combined with script code that is written outside the context of
      formal design methodologies. Few people code without the use of
      an IDE anymore, but there are times that such editors can prove to be
      a crutch.


      However, another, more profound, reason may have to do with the fact
      that it is incredibly difficult when writing procedural class
      code to create a comprehensive model in languages like C++ or Java
      that are uniquely distinct from the view or controller parts of
      an application. In that case, the model is largely symbolic, perhaps
      a drawing laid out in a UML diagram, for instance, but this
      model consequently must be manipulated conceptually rather than
      programmatically. In Java, for instance, if I wanted to create an
      accounting package, I would need to create an abstract model, then
      create a set of Java classes that defined each of the requisite
      pieces, which would in turn handle the view.



      Moreover, while Java contains observer and observable classes, the
      most traditional programming style makes use of event handles
      that place the responsibility of manipulating the environment in the
      body of the object receiving the event, rather than the
      object most like to perform the action. This seemingly trivial
      distinction has a number of long term consequences, not least of
      which being the fact that the event handler code ends up becoming a
      morass of interconnectivity. A publish/subscribe design
      pattern (aka observer/observed) works better in asynchronous
      environments (and what is an event-driven loop but an asynchronous
      environment that ends up having to use complex user-initiated
      threading models and semaphores just to accomodate the high degree
      of interconnectivity.


      XML, of course, maps famously to document object models - what is
      HTML but a slightly broken XML DOM? The ability of XML to
      describe a model has been one of the most significant factors in its
      explosive growth. Intriguingly, however, because it can
      provide a remarkably complete description of a model, it also means
      that the code to manipulate this document object model can be
      reduced to two tools -- one that handles the retrieval of specific
      portions of the model and one that can modify the model in
      response to changes coming from the external environment. In other
      words, you don't need to write code that has to be aware of
      different class interfaces across the boundaries of the model.


      It is in the creation of a universal DOM that I suspect will be one
      of the more significant innovations brought about the XML, and
      ironically it is this point that I think many software vendors are
      deliberately trying to obscure in their marketing. If you can
      turn retrieval of a given property, set of properties or other
      generated data, into an Xpath query against an XML model, for
      instance, then you can essentially encapsulate your logic as a set of
      XPath based rules ... regardless of the components involved.
      You do, admittedly, lose the ability to protect or privatize
      information, but realistically this becomes replaced by the ability
      to transform complex models into more filtered models through the use
      of either internal or external services -- the internal
      state model and the exposed state model do not necessarily have to be
      the same thing.


      I am using DOM here in a very open sense, to include all of the tools
      for manipulating the XML structures -- including such things
      as XPath, XSLT, XQuery, XSD, plus the XML DOM interface itself that
      provides binding rules to other languages. Manipulating the
      underlying XML Model via XSLT is just as valid as making imperative
      DOM calls, though it is worth noting that manipulation by XSLT
      tends to be a replace operation -- any application of business logic
      occurs on a modified copy of the model.


      XML consequently provides a much purer MVC model than Java or C++ (or
      even SmallTalk). The model exists as a document that can
      encode an abstract representation of the model's properties, and can
      be manipulated by a transformative mechanism (XSLT) based
      upon the occurrences of particular patterns. The view may also end up
      being an XML entity (perhaps a presentation language
      instance, such as SVG or XHTML, or perhaps a device control language
      for setting the view to a particular state). What is perhaps
      most significant, however, is the controller.


      In an XML publish/subscribe model (at least the ones I've played
      with), the controller is essentially an event mediator. Each
      object within the model subscribes to events that other objects
      expose. When a subscribed to event occurs, the controller notifies
      the subscribing object. This object can then query the state of the
      rest of the objects in the environment (through the XML Model
      via Xpath) in order to change its own internal state, and
      consequently its representational view.


      Significantly, the non-XSLT code in this kind of architecture is
      substrate oriented. It handles performing the requisite
      transformations, mediating the subscription base and eventing
      mechanisms, and handling specific environmental constraints (actions
      that would be too expensive to handle via transformations, such as
      moving items with a mouse in the view). Even more importantly,
      this code doesn't handle the business logic; this, instead, is
      contained within the XSLT. I will give examples of this in
      subsequent blogs/newsletters.


      A central contention throughout much of my writing is that XML really
      does change programming in very powerful and profound ways,
      and I think we're only just beginning as a whole to make that
      realization. It's a sobering thought, and one that's especially
      crucial when assessing what exactly the role of a programmer should
      be. On the other hand, great periods of technical innovation
      usually occur at transition points, and we're in the process of
      making a significant transition from imperative to declarative
      programming. The next decade should be fun.



      Kurt Cagle is the author or co-author of fourteen books on XML
      Technology, he can be reached at mailto:kurt@... if you
      have any questions or comments about these articles.

      **********************************************
      Copyright 2002 Cagle Communications
      All Rights Reserved
      **********************************************
      To subscribe to this mailing list, send a blank e-mail to
      metaphorical-subscribe@yahoogroups.com or go to
      http://www.kurtcagle.net to sign up and for access to archives.
    Your message has been successfully submitted and would be delivered to recipients shortly.