PLMLx

Extended Pattern Language Markup Language

The intention of PLML is to provide a general structure for pattern documents. The data types of the contents of pattern elements were relaxed to ANY so any type of content could appear within a pattern element (tag).

In some cases I saw that content is marked up using HTML tags. That is OK if a namespace syntax is used.

I got my personal experience writing a pattern collection for CHI2004. To my opinion HTML mark up is not the ideal solution: - HTML can be conform to XML syntax rules, but it has not to be (from the browsers point of view; not W3C). - In most cases we as authors like pretty printed documents e.g. for proceedings. - There are several layout elements far beyond HTML that authors would like to use. - Autogenerated document parts like a TOC are useful and in many cases necessary.

So my aim was to use PLML in such a way that I could write a Pattern collection in an article-like style: with title, abstract, introduction, patterns, biblio, etc.

In my opinion DocBook (http://www.docbook.org) seems to be the right publishing environment where PLM can be nested. So this is a starting for PLMLx:

Enhancing PLML with elements from DocBook (DB) / SimpleDocBook.
Added the PLML element "pattern" to DocBook "article" and "book" to write scientific/technical documents.

Last but not least: found a nice tool DTDDoc (dtddoc.sourceforge.net) to document the PLML DTD.

PLMLx 0.01 change-log

v.0.01 by Diethelm Bienhaus 20.07.2004

"name", "problem", "context", "forces" , "solution" as mandatory elements.

Changed "#PCDATA" datatypes of the main pattern elements to DB "para" because "para" is the main container for text, lists, graphics, etc.
Changed datatype of "illustration" and "diagram" to DB "figure"
The tags "author", "example" are already defined in DB.
Changed "example", "rationale" as first level elements (children of "pattern")
Added "consequences"
Added "ptname" because most authors like a special font effect for pattern names like small capitals. From a technical point of view this tag allows to search in a pattern database or repository especially for pattern names.
Added "ptname", "pattern-link" as inline elements of DB "para" so they can be used within any paragraph. Especially in "related-patterns", of course.
"literature" contains zero or more elements of DB "bibliomixed" (see: http://www.docbook.org/xml/simple/sdocbook/elements/bibliomixed.html)
Added DB element "copyright" to "management".
Added "license" to "management".
"change-log" consists of a sequence of "change". Each "change" is characterized by a version, one or more authors and a description.
"version" contains a major and a minor release number and a date element, when the version was last modified.
Deleted "last-modified" because it is now part of the "version" element of "change"
Added "acknowledgments".

Background

Background information can be found on the Internet: http://www.cs.kent.ac.uk/people/staff/saf/patterns/plml.html

And the CHI2003 workshop report: http://www.cs.kent.ac.uk/people/staff/saf/patterns/CHI2003WorkshopReport.doc

PLML 1.00 change-log

Change log: from the original document plml.1.00.dtd (available at the Internet: http://hcipatterns.org/tiki-list_file_gallery.php)

v.1.1.2 by Susan 26/05/2003. - added collection to pattern (for concistency with pattern-link) v.1.1.1 by Jan, Susan 27/04/2003. - changed order of elements - added change-log in management

v.1.1 by Martijn 21/04/2003. - Relaxed datatypes so that pattern-link can be used almost everywhere. - pattern-link was extended to include new attributes collection and label - Renamed ID to patternID

v.1.0 by Xavier 07/04/2003. - Initial draft.

References

[PLPW] "A Pattern Language for Pattern Writing" Gerard Meszaros, Jim Doble. available on the web from: http://hillside.net/patterns/writing/patternwritingpaper.htm

[Fin2003] "Perspectives on HCI patterns: concepts and tools (introducing PLML)". Sally Fincher. Interfaces, (56):26-28, September 2003. available on the web from: http://www.bcs-hci.org.uk/interfaces.html

pattern is the the root element for a single Pattern.

<pattern>'s children

Name Cardinality

acknowledgments One or none

alias Any number

confidence One or none

context Only one

diagram One or none

example Any number

forces Only one

illustration One or none

implementation One or none

literature One or none

management One or none

name Only one

organization One or none

problem Only one

rationale One or none

related-patterns One or none

resulting-context One or none

solution Only one

synopsis One or none

<pattern>'s attributes

Name Values Default

patternID

Element's model :

(name,alias*,illustration?,problem,context,forces,solution,synopsis?,diagram?,example*,rationale?,confidence?,implementation?,resulting-context?,related-patterns?,acknowledgments?,literature?,organization?,management?)

patternID

Attribute of pattern

the ID of the pattern.

Required

<name>

Child of pattern

A name by which this problem/solution pairing can be referenced. [PLPW]

<name>'s children

Name Cardinality

para Any number

Element's model :

(para)*

<alias>

Child of pattern

Alias names by which this pattern might be known.

Child of pattern

Most pattern forms contain a picture, a really good example of an instantiation of the pattern “in real life”. For HCI patterns this usually means a screen-shot, although it could be a contextualising image (perhaps a photograph of people doing something); multi-media clips are not unknown. [Fin2003]

<illustration>'s children

Name Cardinality

figure Only one

Element's model :

(figure)

Child of pattern

The specific problem that needs to be solved. Use Context-Free Problem to ensure that the problem is kept separate from the constraints on the solution. [PLPW]

DocBook "figure" can contain several types of mediaobjects like image, audio and video. (see: http://www.docbook.org/xml/simple/sdocbook/elements.html)

<problem>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

The circumstances in which the problem is being solved imposes constraints on the solution. The context is often described via a "situation" rather than stated explicitly. Sometimes, the context is described in terms of the patterns that have already been applied. The relative importance of the forces (those that need to be optimized at the expense of others) is determined by the context. [PLPW]

<context>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

The often contradictory considerations that must be taken into account when choosing a solution to a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is implied by the context. [PLPW]

<forces>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

The proposed solution to the problem. Note that many problems may have more than one solution, and the "goodness" of a solution to a problem is affected by the context in which the problem occurs. Each solution takes certain forces into account. It resolves some forces at the expense of others. It may even totally ignore some forces. The most appropriate solution to a problem in a is the one that best resolves the highest priority forces as determined by the particular context. Use Solution Clearly Related to Forces to ensure that the reader understands why this solution was chosen. [PLPW]

<solution>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

This acts as a summary of the pattern, and may be particularly useful for situations where there is limited display-space. [Fin2003]

<synopsis>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

A diagram is different from an illustration. The purpose of a diagram is to communicate to the user of the pattern—the designer—details that are more readily expressed (and apprehensible) in schematic form. Sometimes this is a free-hand sketch; sometimes it is a more formal representation, such as UML. [Fin2003]

<diagram>'s children

Name Cardinality

figure Only one

Element's model :

(figure)

Child of pattern

All the patterns in this language have Mandatory Elements Present. This ensures that potential users of these patterns understand why and when to apply them. The elements are highlighted through the use of headings. Most of these patterns start with the Problem statement followed by the Context, while others start with the Context. This was done to illustrate both styles. [Berczuk96] consistently places the Context before the Problem section. [PLPW]

A pattern goes beyond a mere description of the solution by providing a window on the thought processes behind choosing the solution. The mandatory pattern elements described here are essential to communication of this information. In the many patterns that have been written since The Timeless Way of Building [Alexander79] and A Pattern Language [Alexander77] were first published, these mandatory elements have been found to be the minimum information required to effectively communicate a pattern. [PLPW]

<rationale>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

If used, we propose that this should be expressed as a rating, normally a star-rating (following the system used in A Pattern Language (Alexander et al., 1977): zero, one or two-stars). [Fin2003]

Child of pattern

References of the pattern to other works like papers and books. In case of a pattern language or collection a tool (e.g. a XSL processor) can collect all bibliographical entries for the reference list.

<literature>'s children

Name Cardinality

bibliomixed Any number

Element's model :

(bibliomixed)*

Child of pattern

Some patterns exspecially from technical domains come with code or code fragments showing how to implement the pattern.

<implementation>'s children

Name Cardinality

para Any number

Element's model :

(para)*

<resulting-context>

Child of pattern

The context that we find ourselves in after the pattern has been applied. It can include one or more new problems to solve. This sets us up for applying more patterns, possibly the next pattern(s) in a language. [PLPW]

<resulting-context>'s children

Name Cardinality

para Any number

Element's model :

(para)*

<related-patterns>

Child of pattern

Other patterns that may be of interest to the reader. The kinds of patterns include:

Other solutions to the same problem,
More general or (possibly domain) specific variations of the pattern,
Patterns that solve some of the problems in the resulting context (set up by this pattern)

[PLPW]

<related-patterns>'s children

Name Cardinality

para Any number

Element's model :

(para)*

<pattern-link/>

Link to another pattern

<pattern-link>'s attributes

Name Values Default

collection
label
patternID
type

This tag is always empty.

type	Attribute of pattern-link

Type of the pattern link

Required

patternID

Attribute of pattern-link

unique ID of the pattern

Required

collection

Attribute of pattern-link

collection that contains the pattern

Required

label

Attribute of pattern-link

label of this link

Required

Child of pattern

You should acknowledge anyone who contributed significantly to the development of the pattern (or language) or the techniques described in it. If your pattern has been through a "shepherding process" or "writer's workshop", significant contributors (such as the shepherd!) are candidates for being acknowledged. [PLPW]

<acknowledgments>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of pattern

Organisational meta data of a pattern. A single pattern may be part of several collections.

<organization>'s children

Name Cardinality

category One or none

classification One or none

collection Any number

Element's model :

(collection*,classification?,category?)

Child of organization

One entry in the sequence of collections that contain this pattern.

Child of organization

There are several approaches to classify patterns: GoF, POSA or Linda Rising's work. Maybe, once upon a time in the future there will be a common taxonomy. At least, here is an element for that.

Child of organization

Category of the pattern like "HCI", "Organizational" or "Pedagogical", etc.

Child of pattern

Meta data of the pattern. "author" is already defined in DocBook.

<management>'s children

Name Cardinality

author One or none

change-log Only one

copyright One or none

creation-date One or none

credits One or none

licence One or none

revision-number One or none

Element's model :

(author?,revision-number?,creation-date?,change-log,credits?,copyright?,licence?)

<creation-date>

Child of management

Creation date.

<creation-date>'s children

Name Cardinality

date Only one

Element's model :

(date)

Child of management

Credits

<revision-number>

Child of management

To fix : How are revision-number and version related

<last-modified>

last modification

Pattern name: either a String or a URL link

<ptname>'s children

Name Cardinality

ulink Any number

Element's model :

(#PCDATA | ulink)*

<change-log>

Child of management

Change-log contains a sequence of "change".

<change-log>'s children

Name Cardinality

change Any number

Element's model :

(change*)

Child of change-log

Each "change" is defined by a version, one or more authors and a description.

<change>'s children

Name Cardinality

author At least one

description Only one

version Only one

Element's model :

(version,author+,description)

Child of change

Version numbers should be given in a way similar to software releases. After important changes the major number is incremented. Smaller revisions are count in the minor number. Each version has a date element.

<version>'s children

Name Cardinality

date Only one

majorNr Only one

minorNr Only one

Element's model :

(majorNr,minorNr,date)

Child of version

After important changes the major number is incremented.

Child of version

Count for smaller revisions.

Child of change

description what was changed

<description>'s children

Name Cardinality

para Any number

Element's model :

(para)*

Child of management

License under which the pattern is published. E.g. the "GNU Free Documentation License", "Common Documentation License" or the "Open Publication License". The URL of the license is an optional element.