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." <40FFE30B.601@ba-nordhessen.de> 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: http://www.cs.kent.ac.uk/~saf/patterns/gallery.html) 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 http://www.cs.kent.ac.uk/people/staff/saf/index.html 'phone: +44 1227 764000 ext.4061 fax: +44 1227 762811 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++