First things first, my apologies but I am not talking about an existing technology in this blog. I am not even talking about a complete concept for a future technology.
This blog is just about an idea only. An idea for applying aspect orientation to XML, nothing more and nothing less. I am blogging this idea to see if anyone has any thoughts on the potential concept, a brain dump really to see if anyone has thought about things this way and, even better, possibly has got it sorted out already. So my apologies up front if this is a done deal, but I wanted to raise the questions.
Now that I’ve got that out of the way I’ll explain a little about where I’m coming from. I’m a heavy user of Aspect Orientation (AO) in regards to Java. I’ve really found some distinct advantages of an architecture based upon aspects and objects rather than objects on their own. Right through from simple applications, sometimes just single classes, to large complex deployments, advantages can be reaped from modularising areas on the micro scale, right down to methods, through to the macro system-wide concerns. As mentioned before on these blogs, AspectJ et al already nail aspect orientation to a large degree for Java and other Object Oriented (OO) languages and this is starting to become a more recognised approach to architecting software applications.
But what about data itself….? or for the sake of discussion on this blog, what about XML?
XML offers the capability to create elegant hierarchies of relationships between data elements. Similar to the more familiar Object Oriented hierarchies, XML offers many good things when it comes to specifying the business data of a system to the right level of abstraction.
However, in XML based systems, not unlike OO hierarchies, there are some types of problem that do not sit well when interleaved with the business logic of a system. Aspects such as security that cross-cut the XML hierarchy are interleaved with the rest of the XML business logic schema definition and this seems to me to lead to some of the same problems that aspect orientation attempts to solve in OO hierarchies.
So, can XML benefit from an AO perspective? That’s the question that this blog throws out there for anyone who’s interested.
My thoughts on the concept are in the very early stages, and I’ll be the first to admit that I don’t have the worlds most comprehensive knowledge of XML and all it’s associated technologies (and acronyms!), but it seems to me that there may be scope for something here.
XSLT offers some of the answer from what I’ve gathered so far. XSLT builds on the capabilities of XPATH (ohhh, there’s never enough acronyms) and offers the ability to transform XML instances from one form to another, from one schema to another. XML Schema themselves are XML instances and so this transformation can work with the schema as well.
This is where I start to see a potential advantage to using aspect orientation in XML creation and processing. So far, my thoughts only go as far as the following simple example. And quite obviously I can’t currently offer much in terms of practical tools that put forward how this processing can be done. But maybe this example might get some of the XML experts out there to pipe up and either tell me that ‘hey, this has been done before … just use…’ or generate some interest in potentially taking this further.
I’ve been thinking of a simple example to illustrate how such an architecture might work. First of all I define the simplest business logic schema my lecturers at Oxford could put together for the recent XML module (thanks to Steve and Ian for such an interesting module).
The following is a simple XML Schema for a greetings message
<?xml version="1.0"?>
<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:element name="Greeting" "type=xs:string"/>
</xs:schema>
So we’ve got a very simple XML schema, here’s an instance of that schema.
<?xml version="1.0"?>
<Greeting>
Hi there
</Greeting>
It is also possible that you could have a schema that defines a more cross-cutting issue such as security classification.
<?xml version="1.0"?>
<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:element name="SecurityClassification" "type=xs:string"/>
</xs:schema>
Then we can create a representative instance of this Security aspect schema.
<?xml version="1.0"?>
<SecurityClassification>
Restricted
</SecurityClassification>
Security is a fairly common and useful cross-cutting concern. The data encapsulated within a business schema may benefit from security being applied to many elements within the document and it is this weaving characteristic that draws some parrallels to aspect orientation in more traditional OO languages.
So how could these two disparate schemas and instances be woven together in-line with aspect oriented methods? Figure 1 shows one way that the aspect weaving could take place producing a woven schema and instance from the examples above.
Figure 1. A possible architecture for XML aspect weaving
The process in this architecture is simple enough. Due to the fact that XML schema and instances are both XML then XSLT can be used to provide a form of pointcut-like logic for applying the advice-like data elements encapsulated in the SecurityClassification schema and it’s instances. The instances and the schema are woven to produce a traditional XML schema and instance that has the cross-cutting information, the aspects, applied.
So what would be an expected output from such a process? The following schema and instances are one possible output from such a process, highly dependant on the XSLT pointcut-like definitions shown in Figure 1.
<?xml version="1.0"?>
<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:element name="SecureGreeting">
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityClassification" "type=xs:string"/>
<xs:element name="Greeting" "type=xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version="1.0"?>
<SecureGreeting>
<SecurityClassification>
Restricted
</SecurityClassification>
<Greeting>
Hi there
</Greeting>
</SecureGreeting>
So are we just talking about XSLT? Yes and no. We are talking about using XSLT, but the perspective is important. We are using XSLT to weave cross-cutting aspects in our XML. Although the technologies potentially exist already it is the perspective change towards aspect orientation that is crucial if any advantages are to be harnessed.
Ok, so that’s a very simple example of what AspectXML could be. By illustrating the ideas I’ve been kicking about I’m hoping to promote some discussion on this, even if it is along the lines of ‘we’ve discounted this ages ago!’. That would be totally fine by me.
I can see the same simple concepts shown in this example possibly aiding in the creation and processing of far more complex XML schema. I don’t have all the answers to the questions that AspectXML proposes. I’m not even sure I have all the questions straight. I could be way off in left field on this, but I can see advantages to the AO perspective for XML even if the approach here is wrong.
Some of the advantages to such an approach are effectively stated as the advantages of AO in general. AO gives us the ability to modularize cross-cutting concerns to better create and manage these areas within our application and/or data.
It is the disadvantages that can be more important to ay new concept and in this case the stand-out problem is that writing the XSLT’s is hard. Unfortunately things seem immature enough at this point to not have commonly reusable design patterns for XSLT available. The power of this suggested concept for AO in XML is in the XSLT’s but unless these can be made easier to create in terms of reusability then this trickiness of XSLT could hold things up. It’s possible that the first efforts then down the path of AO XML could be in terms of XSLT patterns and mechansims for their implementation and reuse. That in itself would be a nice generic piece of work to aid everyone. Hopefully that effort could then perhaps feed into the development of aspect orientation in XML processing at a later date or even alongside that work. But maybe I’m getting ahead of myself a bit now.
I’ll be the first to admit that this is just an idea. If anyone has the time to look into this (or offer some suggestions for how this is already done) then I’m definitely interested. I’m a lazy software guy, and if something has been done before then I’m more than happy to buy into someone else’s concepts. But from what I understand at the moment I can see some definite uses for such an aspect oriented approach to XML and it would be great to hear from anyone who has the time to help me pursue this a little further.
So there’s an idea for AO in XML. Any thoughts from those out there in the XML field?
