Since you've come this page, you probably already know that:
- The eXtenisble Markup Language (XML) is a newly endorsed standard for creating and exchanging structured documents. It is similar to HTML, except that it goes even further in separating presentation and content. [The XML 1.0 specification was released as a W3C Recommendation on February 10, 1998. More information can be found at www.w3.org/XML/ (the World Wide Web Consortium) or www.xml.com (the "XML commune")].
- Patterns and pattern languages are problem-solving and solution-documenting techniques that can be traced to the architect Christopher Alexander. Patterns are increasingly popular in software design, due in large part to the "Gang-of-Four", who wrote a book entitled Design Patterns: Elements of Reusable Object-Oriented Software in 1994. [The Hillside Group's "patterns home page" at www.hillside.net/patterns/patterns.html is probably the best hub for software related pattern activity on the web.]
Below you'll find my first stab at creating a document type definition (DTD) for documenting patterns in XML. A similar document has been created by Steve Roggenkamp. It can be found at www.infinet.com/~sroggen/patterns/patlangdtd.html.
An example of using this DTD to mark-up a pattern, together with some example renderings of that markup is available.
Recently I have been looking into creating a "pattern server" for the company I work for. (The Planet Group, check us out at www.pg.net.) This server would allow Planeteers to publish, search and cross reference software and organizational patterns online, resulting in all those great pattern-sharing benefits.
Given the design philosophy, the already structured format of patterns and pattern languages, and the power and utility of XML, creating and using a DTD for patterns seems like a natural choice. I wrote up some notes, sent them to the patterns-discussion mailing list and solicited comments and suggestions. (This is also how I was pointed to Steve's page.) I have incorporated many of those suggestions here.
Given the importance of collaboration and exchange in the patterns community, it seems to me that this should be a group effort. For this reason I am publishing my draft here. Please feel free to comment on, improve, or steal the DTD entirely--just let me know what you do with it. We (the pattern community) would all benefit from a standard format for pattern exchange. Consider this a request for comments.
In any case, I am pushing ahead with the "pattern server" work. I'd be willing to share code, if you're interested you can email me at rod@pg.net or rwald@hotmail.com.
When I first began to consider the idea of a pattern server, largely using the wiki server (www.c2.com/cgi/wiki) as a prototype, I came up with the following desirata:
- it should be easy to contribute patterns, written both online and off
- it should be easy to cross reference the patterns, ala wiki, since forming networks or languages is what patterns are all about
- it should be easy to vary presentation style or document arrangement, since different pattern forms are more appropriate in different situations
- patterns should be well formed (contain a core set of elements), unlike in wiki, which is arguably just a non-linear threaded discussion board.
- it should be easy to search the patterns, not just as full text or by keyword, but by individual section
- it should be easy to extract summaries or thumbnail descriptions of patterns for use in pattern catalogs or when providing an index of external patterns (making individual pattern documents more self-contained, but reducing maintenance overhead)
Clearly XML is a natural choice for this. In practice, my pattern server will likely be a collection of Java Servlets that can parse the XML documents and spit out HTML (since there is little client-side XML support) as well as query and report upon the document store. Regardless, using a well-formed XML DTD will make it easier to utilize these documents as pure XML.
A few XML-specific requirements are worth noting:
- markup should be easy to use--we hope that non-technical users will contribute as well (patterns don't have to be about software, after all--I'd love to see a pattern language for sales and client relations, for example.)
- markup should allow some degree of control over document formatting (using the html <i> and <b> tags, for example) but should largely focus on describing the document's structure.
- the variety of pattern forms should be supported
- the DTD should be easy to extend. I need help here. Do we just litter ANYs around? Won't that make it hard to do anything useful with the documents?
The DTD below contains a number of comments and indications of areas in need of work, but in this section we outline some issues in need of particular attention.
- First and foremost, the DTD below is probably not well formed. Any comments or corrections regarding that (or a pointer to a good DTD reference) would be greatly appreciated.
- Some subset of HTML should be supported. Steve's DTD defines many HTML tags. It is assumed that some of these will eventually be included here. The question is: which ones?
- We definitely need a mechanism for including images. Perhaps the HTML <img> tag or something utilizing the XLL (XML Linking Language).
- It seems important to be able to cross reference patterns beyond a particular collection or server. Some sort of universal identifier for patterns is necessary. (The Java package specifying convention, e.g. COM.MyCompany.PackageName.ClassName is a very intriguing prototype, since this would theoretically allow us to locate a pattern on the web from its name alone.
- There is currently no element for identifying pattern languages. Steve's DTD uses patlang as the base element, and groups patterns inside of it. I think it is important to be able to use patterns in more than one language, as in Alexander, so perhaps some orthogonal pattern language DTD is required.
- The distinction between the entities %patsect and %enumpatsect are probably artificial.
- I've included most, if not all, of the sections I have seen used in patterns and pattern forms. This list could probably be condensed, as several are practically synoymous.
- Any thoughts on what should be the basis for a "core" pattern are welcome. I'm currently using name, context, problem, solution--basing this on the notion of patterns as a "named solution to a problem within a context", although to the Alexander-purists its probably not a pattern if it doesn't involve explicit forces.
The latest draft (Revision 0.2 1998.06.22) is pat_dtd_0_2.html.
Previous versions include:
- Revision 0.1 1998.06.18 [pat_dtd_0_1.html.]
Feel free to commment to rod@pg.net or rwald@hotmail.com.
When you write, be sure to mention whether or not you want your comments added to the comment archive; otherwise, I'll assume you don't mind being listed.
- answer the open questions
- post or link to a simple XML parser (state-diagram, Java code)
- Pattern Server Servlets