Date:    Fri, 23 Jul 2004 16:39:37 BST
To:      Diethelm Bienhaus 
From:    S.A.Fincher
Subject: Re: PLML 

In-Reply-To: Your message of "Thu, 22 Jul 2004 17:53:47 +0200."

Diethelm -

> the pattern workshop at CHI 2004 was my first contact with PLML. I did 
> some work incorporating PLML and DocBook and writing XSLT stylesheets to 
> convert PLML to PDF.
> Attached you'll find a documentation for an extended version of PLML.
> Hope this might be of your interest. Looking forward for your feedback.

Thank you, yes. This is most interesting, and you have made some
nice integrations & improvments. I'll be happy to add it (or
a link to it) from the PLML page I'm keeping. However, I do
also have some concerns:

PLML was originally devised so that HCI patterns authors could share a
common standard, and so that it would be possible to build
cross-collection pattern "languages". PLML therefore, has minimal
mandatory elements.  By making "problem", "context", "forces" and
"solution" mandatory, you are doing two things:

* Firstly, you are forcing pattern-authors to follow the form you
  define. This is certainly against the spirit of PLML.

* Secondly, by making these elements mandatory, you are excluding
  some quite influential people - Jenifer Tidwell's new collection "UI
  Patterns and Techniques" for example, has NONE of those element you
  have decided are essential, and the pure Alexandrian form that Jan
  used in his book does not separate out "context" and "forces"
  (See the collection of forms in the Pattern Gallery at:

I think the more items you make mandatory, the less it is likely 
that PLML will be useful, or will be used. So I would suggest that
you return these elements to "optional" status.

I also disagree with making "rationale" and "example" first level
elements. I disagree becuase by doing that you destroy their *function*
in the pattern-form. Their function is to provide evidence of why what
you are describing is a _pattern_, either from an intellectual
construction or from a synthesis over a variety of examples (or,
preferably, both). By making them first-level elements pattern authors
lose the "reminder" of what purpose these sections serve. So I would
suggest that you re-instate the element "evidence", and make 
"rationale" and "example" optional second-level elements of it.

Finally, I find "resulting context" problematic. Partly, I happily
admit, this is because of my personal opinion that such an element has
no place in any pattern - but then I don't like "context" either. (I
think that if you don't know why you want to use a pattern, and you
don't know what sort of effect you seek then "context" and "resulting
context" are not going to help you very much. And I take a pretty hard
line that these things are properly expressed through a pattern
language's structuring principle, and the only reason that authors want
to use them is becuase HCI patterns are almost always standing alone
and outside of any structure).

However, I also find it problematic becuase there are only a couple of
HCI pattern-forms that use "resulting context", and in all cases I
think that what they have to say there could be easily stated within
"related patterns". So I think it's unnecessary.

I hope this helps

- Sally

Sally Fincher, Computing Laboratory, University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, UK

'phone: +44 1227 764000 ext.4061 fax: +44 1227 762811