<?xml version="1.0" encoding="UTF-8"?>
<!--
<h2>Extended Pattern Language Markup Language </h2>
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:
<ul>
<li>Enhancing PLML with elements from DocBook (DB) / SimpleDocBook.</li>
<li>Added the PLML element "pattern" to DocBook "article" and "book" to write scientific/technical documents.</li>
</ul>
Last but not least: found a nice tool DTDDoc (dtddoc.sourceforge.net) to document the PLML DTD.
<h3>PLMLx 0.01 change-log</h3>
v.0.01 by Diethelm Bienhaus 20.07.2004
<ul>
<li>"name", "problem", "context", "forces" , "solution" as mandatory elements.</li>
<li>Changed "#PCDATA" datatypes of the main pattern elements to DB "para" because "para" is the main container for text, lists, graphics, etc.</li>
<li>Changed datatype of "illustration" and "diagram" to DB "figure"</li>
<li>The tags "author", "example" are already defined in DB.</li>
<li>Changed "example", "rationale" as first level elements (children of "pattern")</li>
<li>Added "consequences"</li>
<li>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.</li>
<li>Added "ptname", "pattern-link" as inline elements of DB "para" so they can be used within any paragraph.
Especially in "related-patterns", of course.</li>
<li>"literature" contains zero or more elements of DB "bibliomixed" (see: http://www.docbook.org/xml/simple/sdocbook/elements/bibliomixed.html)
</li>
<li>Added DB element "copyright" to "management". </li>
<li>Added "license" to "management". </li>
<li>"change-log" consists of a sequence of "change". Each "change" is characterized by
a version, one or more authors and a description.
</li>
<li>"version" contains a major and a minor release number and a date element, when the version was last modified.</li>
<li>
Deleted "last-modified" because it is now part of the "version" element of "change" </li>
<li>
Added "acknowledgments".
</li>
</ul>
<h3>Background</h3>
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
<h3>PLML 1.00 change-log</h3>
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.
<h3>References</h3>
[PLPW] "A Pattern Language for Pattern Writing" Gerard Meszaros, Jim Doble.
available on the web from: <a href="http://hillside.net/patterns/writing/patternwritingpaper.htm">http://hillside.net/patterns/writing/patternwritingpaper.htm</a>
[Fin2003] "Perspectives on HCI patterns: concepts and tools (introducing PLML)". Sally Fincher. Interfaces, (56):26-28, September 2003.
available on the web from: <a href="http://www.bcs-hci.org.uk/interfaces.html
">http://www.bcs-hci.org.uk/interfaces.html
</a>
@title PLMLx
@root pattern
-->
<!--
<b>pattern</b> is the the root element for a single Pattern.
-->
<!ELEMENT pattern (name, alias*, illustration?, problem, context, forces, solution, synopsis?, diagram?, example*, rationale?, confidence?, implementation?, resulting-context?, related-patterns?, acknowledgments?, literature?, organization?, management?)>
<!--
@attr patternID the ID of the pattern.
-->
<!ATTLIST pattern
patternID CDATA #REQUIRED
>
<!-- for documentation only in comment
<!ENTITY % docbook.dtd SYSTEM "sdocbook.dtd">
%docbook.dtd;
-->
<!--
A name by which this problem/solution pairing can be referenced. [PLPW]
-->
<!ELEMENT name (para)*>
<!--
Alias names by which this pattern might be known.
-->
<!ELEMENT alias (#PCDATA)>
<!--
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]
-->
<!ELEMENT illustration (figure)>
<!--
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)
-->
<!ELEMENT problem (para)*>
<!--
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]
-->
<!ELEMENT context (para)*>
<!--
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]
-->
<!ELEMENT forces (para)*>
<!--
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]
-->
<!ELEMENT solution (para)*>
<!--
This acts as a summary of the pattern, and may be particularly useful for situations where there is limited display-space. [Fin2003]
-->
<!ELEMENT synopsis (para)*>
<!--
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]
-->
<!ELEMENT diagram (figure)>
<!--
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]
<!ELEMENT example (para)*>
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]
-->
<!ELEMENT rationale (para)*>
<!--
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]
-->
<!ELEMENT confidence (#PCDATA)>
<!--
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.
-->
<!ELEMENT literature (bibliomixed)*>
<!--
Some patterns exspecially from technical domains come with code or code fragments showing how to implement the pattern.
-->
<!ELEMENT implementation (para)*>
<!--
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]
-->
<!ELEMENT resulting-context (para)*>
<!--
Other patterns that may be of interest to the reader. The kinds of patterns include:
<ul>
<li>Other solutions to the same problem,</li>
<li>More general or (possibly domain) specific variations of the pattern,</li>
<li>Patterns that solve some of the problems in the resulting context (set up by this pattern)</li>
</ul>
[PLPW]
-->
<!ELEMENT related-patterns (para)*>
<!--
Link to another pattern
-->
<!ELEMENT pattern-link EMPTY>
<!--
@attr type Type of the pattern link
@attr patternID unique ID of the pattern
@attr collection collection that contains the pattern
@attr label label of this link
-->
<!ATTLIST pattern-link
type CDATA #REQUIRED
patternID CDATA #REQUIRED
collection CDATA #REQUIRED
label CDATA #REQUIRED
>
<!--
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]
-->
<!ELEMENT acknowledgments (para)*>
<!--
Organisational meta data of a pattern. A single pattern may be part of several collections.
-->
<!ELEMENT organization (collection*, classification?, category?)>
<!--
One entry in the sequence of collections that contain this pattern.
-->
<!ELEMENT collection (#PCDATA)>
<!--
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.
-->
<!ELEMENT classification (#PCDATA)>
<!--
Category of the pattern like "HCI", "Organizational" or "Pedagogical", etc.
-->
<!ELEMENT category (#PCDATA)>
<!--
Meta data of the pattern. "author" is already defined in DocBook.
-->
<!ELEMENT management (author?, revision-number?, creation-date?, change-log, credits?, copyright?, licence?)>
<!--
Creation date.
-->
<!ELEMENT creation-date (date)>
<!--
Credits
-->
<!ELEMENT credits (#PCDATA)>
<!--
@fixme How are revision-number and version related
-->
<!ELEMENT revision-number (#PCDATA)>
<!--
last modification
-->
<!ELEMENT last-modified (#PCDATA)>
<!--
Pattern name: either a String or a URL link
-->
<!ELEMENT ptname (#PCDATA | ulink)*>
<!--
Change-log contains a sequence of "change".
-->
<!ELEMENT change-log (change*)>
<!--
Each "change" is defined by a version, one or more authors and a description.
-->
<!ELEMENT change (version, author+, description)>
<!--
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.
-->
<!ELEMENT version (majorNr, minorNr, date)>
<!--
After important changes the major number is incremented.
-->
<!ELEMENT majorNr (#PCDATA)>
<!--
Count for smaller revisions.
-->
<!ELEMENT minorNr (#PCDATA)>
<!--
description what was changed
-->
<!ELEMENT description (para)*>
<!--
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.
-->
<!ELEMENT licence (licencetype, ulink?)>
<!--
License type like "GNU Free Documentation License", "Common Documentation License" or the
"Open Publication License".
-->
<!ELEMENT licencetype (#PCDATA)>
<!--
<!ELEMENT article ((%div.title.content;)?, articleinfo?, tocchap?, lot*,
(%bookcomponent.content; | pattern)*,
((%nav.class;) | (%appendix.class;) | ackno)*
)>
-->
<!-- for documentation only -->
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/para.html">para</a>
-->
<!ELEMENT para (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/author.html">author</a>
-->
<!ELEMENT author (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/example.html">example</a>
-->
<!ELEMENT example (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/copyright.html">copyright</a>
-->
<!ELEMENT copyright (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/figure.html">figure</a>
-->
<!ELEMENT figure (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/link.html">link</a>
-->
<!ELEMENT link (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/ulink.html">ulink</a>
-->
<!ELEMENT ulink (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/date.html">date</a>
-->
<!ELEMENT date (#PCDATA)*>
<!--
see documentation at oasis-open: <a href="http://www.oasis-open.org/docbook/xml/simple/sdocbook/elements/bibliomixed.html">bibliomixed</a>
-->
<!ELEMENT bibliomixed (#PCDATA)*>