Brainstorming Aspect Orientation in XML

by Russell Miles



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="http://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="http://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.




image



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="http://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?


9 Comments

fsauer65
2004-03-22 09:21:01
XSLT is XML too
SInce XSL itself is XML as well, one could write one generic XSLT that takes some kind of aspect specification XML into XSLT, which then in turn can weave the aspects. That way, we don't have to write new XSLT weavers for every problem. Instead, we could write using familiar terminology, like (hope I can type XML here):





In fact, I've already written something leveraging some of the AOP concepts in an XML like tranformation language I called FPL. See
http://www.volantec.biz/Metadata-driven.pdf, which I presented at an OOPSLA workshop in Seattle in 2002

fsauer65
2004-03-22 09:33:05
XSLT is XML too
SOme more thoughs and a better way to write the example just occurred to me:





in other words, use xpath expression and pointcuts to introduce new aspects nefore, after, or around(?) the pointcuts identified by the xpath expression. I introduced a namespace because I can envision having snippets of XSL or schema in here as well.


Frank

russellmiles
2004-03-23 01:20:59
XSLT is XML too
Cheers for the comments Frank.


I'm wondering if it's worth setting up some sort of project/discussion forum in addition to this blog?


I really like these concepts and wonder if it's worth trying to put something together as a more complete article. Also it might be a nice addition to the AOSD discussions next year in Chicago which I am planning to attend.


If you're interested then please contact me via email.


Thanks again for the ideas!

bazzargh
2004-03-23 03:09:59
Return of the MOP
Part of the reason that Aspects are such a relevation in java is that the language doesn't have the meta-facilities that make this stuff easy. Its no accident that Gregor Kiczales co-authored Art of the Metaobject Protocol on Common Lisp , then went on to invent aspect oriented programming.


There were similar comments at the start of the design patterns movement, that in sufficiently powerful languages, patterns were almost too obvious to have been discussed.


The relevance of all this, is that XSL-T is an XML-ization and simplification of DSSSL, a lisp-like language. They share the property that there's no distinction between code and data structures, so its relatively simple to use XSL-T to transform XSL-T, and people have been doing this since day 1.


That being said, your focus is more on crosscutting concerns in data. You should take a look at APEX which does something similar, a kind of reuse called "architectural forms" in the SGML world.


If you're looking for XSL-T design patterns, see here, here and here(look at exslt examples of named templates).


I don't mean to come across as hypercritical here (or as a lisp nut). Applying aspect-oriented concepts to xml isn't a stupid idea at all, but recognizing the common heritage aspects and xsl have in lisp might also help you to bring this together as code.

BobDuCharme
2004-03-24 06:49:18
"trickiness of XSLT" not the problem

The problem of combining two schemas into one and combining documents that conform to those schemas into one that conforms to the combined schema is more general than anything that can be blamed on XSLT syntax and features--doing it with your favorite programming language and a SAX or DOM API won't make it any easier. Your black boxes--or rather, gray ovals--have a lot of work to do, particularly the first one, because a generalized way to combine two schemas is impossible. That's why fsauer65's suggestion for developing aspect specifications to guide the weaving process makes a lot of sense, because the black boxes need some instructions as to what goes where in the combined versions.


(Interesting note: a Google search on "aspect oriented programming" turns up one single paid ad on the right, with a header of "Work at Google" and the description "Google is hiring expert computer scientists and software developers!")

russellmiles
2004-03-24 07:12:34
"trickiness of XSLT" not the problem
Once again, great comments from everyone!


I really like the comments on writing the aspect specifications using XML from Frank too and I am looking at coming up with some examples of this working when I get 5 mins spare (not often unfortunately).


I am also trying to digest all the information on LISP and the heritage of AOP which I had not investigated to anywhere near the level that was mentioned below. Hopefully I can come up with something more concrete for an article and if anyone is interested in helping out then please contact me.


Thanks again!

russellmiles
2004-03-24 10:03:06
XSLT is XML too
I'm taking a look at how AspectWerkz denotes pointcuts and aspects in XML to see if there is some cross-over with your concepts here. It looks like there might be quite a bit of reuse in a concept implementation by taking the schema defined for aspectwerkz and amending the pointcut definitions into XPATH statements ....


Thanks for the thought train! at least now it's on the move again.

functionalx
2004-04-22 05:38:07
AspectXML.org is live and functional
A quick update to anyone who reads this blog and is not already involved with the project that has stemmed from its posting. This idea has blossomed into a fully fledged open source project whos existence has already outgrown the capacity of an ADSL line located in the UK. The site has since been moved to a faster and more reliable server/bandwidth combo and is once again live and ready for action. The project is currently in version 0.8 and the bits are available for immediate download. Please visit AspectXML.org for more details on the project, latest bits avaialable for download, a community forum to ask questions and get answers, and so on. Thanks for your interest!
luciana
2006-05-03 15:53:52
Hi...
in fact I was just thinking about that.... I´m doing my researchs on that point... aspect orientend, XML and schema... I´m including that on my thesis.....