OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XML Design Patterns

[ Lists Home | Date Index | Thread Index ]
  • From: "Rick Jelliffe" <ricko@allette.com.au>
  • To: <xml-dev@ic.ac.uk>
  • Date: Sun, 12 Dec 1999 17:06:41 +0800


From: Toivo Lainevool <tlainevool@yahoo.com
>Does anyone have any references to XML design patterns, seems like a
great
>idea.

There are three main references.

1) The first is Ian Graham and Liam Quin's web pages "Introduction to
XML
Design Patterns" at
http://www.groveware.com/xmlbook/patterns.html

They give:
  * Running Text Pattern
  * Generated Text Pattern
  * Footnote Pattern
  * Text Blocks Pattern

This is just a teaser site: I expect (or at least, I would love to see)
a full book
or website along those lines.

2) The second is my book:

  The XML & SGML Cookbook: Recipes for Structured Information
  Charles F. Goldfarb Series on Open Information Management
  Prentice Hall, 1998, ISBN 0-13-614223-0, 650 pages

In researching that book I spent 1 year looking through as many DTDs
as I could to try to discover the patterns they contained. I began
trying to
use Alexander's pattern approach (which is just as much a rhetorical
form
as it is a methodology) but ultimately I abandoned it because:

    * Many entries were trivial (e.g., Q. "When should you use a list
pattern?"
A. "Whenever you need a list")

    * Many entries only made sense after an analytical framework was
first established:  in fact, the first third of the book ("Systems of
Documents") was spent establishing such a framework/vocabulary
for the second third ("Document Patterns"). The last third of the
book ("Characters & Glyphs") similarly had to cover a lot of
analytical ground (e.g. the ISO Character/Glyph model) before
moving on to patterns.

    * It was clear that the SGML literature had not even began to cover
this kind of area: I am not smart enough to single-handedly establish
a pattern vocabulary--indeed, it is only possible as a community
effort--
so the best I could do was to try to set things up.

    * There was some opposition to the idea that you could usefully
construct
DTDs from prefabricated components, rather than by doing extensive
document analysis.  So the pattern approach was dismissed by some:
in particular, the idea that one could appropriate elements from a "toy"
DTD like HTML;
of course, with the advent of namespaces, the idea of reusable
vocabularies
is now utterly accepted: I don't know if my book contributed to that.

    * Many patterns made sense only in distinction from some other type:
so I moved towards a more "X versus Y" style.

    * Alexander gave an interview (in "Computer Languages" magazine?
perhaps with Michael Swaine?) in which he said how disappointing the
results of the early uses of his pattern language in architecture had
been.
He said that rather than creating functional and innovative buildings,
people applied patterns and made buildigs that looked the same. So
pattern languages seemed good for QA but not for excellence. Because
I view DTDs as a tool for software engineering rather than data
modeling,
it made sense to try to integrate patterns into a software engineering
framework, for my point of view.

Here is most of the "Index of Patterns, Stuctures & Forms" from my book:
    * active versus passive (DTD style)
    * address
    * analytical domain
    * architectural form
    * attribute v. element (DTD style)
    * base (element set)
    * building block versus paragon (DTD style)
    * calendar
    * catalog
    * character versus glyph
    * character set
    * citation
    * class (attribute)
    * color
    * continuation paragraph
    * core (element set)
    * country code
    * cross-reference
    * data attribute for element
    * database versus literature (DTD style)
    * date
    * default value list
    * definition list
    * derived (element set)
    * description table
    * document
    * editorial structure (view)
    * element reference (reflection)
    * embedded data
    * encoding
    * fielded names
    * fielded text
    * floating elements
    * font
    * fragment
    * generic versus specific (DTD style)
    * gestural domain
    * hyperlink
    * identifier
    * IETM
    * information unit
    * inline versus interlaced
    * internal markup versus external markup (DTD style)
    * language
    * language codes
    * lexical type
    * linear versus nested (DTD style)
    * line
    * logical domain
    * loose versus tight (DTD style)
    * marketplace versus hierarchy (DTD style)
    * metadata
    * microdocument
    * name (ID)
    * nested paragraph
    * note (endnote, footnote, annotation, warning, caution)
    * occurrence
    * page object (View)
    * page layout (View)
    * paragraph
    * paragraph group (aka formal paragraph)
    * pool
    * prototypes
    * reusable components
    * ruby annotation
    * running text
    * self-labelling versus extenal labelling (DTD style)
    * semi-graphical text
    * sequence (generic)
    * sequence (list)
    * schema
    * stylesheet
    * subparagraph
    * table
    * text block
    * time and space
    * type extension
    * unspecified
    * visual domain
    * word segment

(You can imagine my surprise when a review said that most of my book
was found elsewhere, when in fact, it is still the only thing available
persuing the pattern idea--though not the literature form :-(   )

One very easy way to gather patterns is to look in DTDs for the things
that parameter entities name. These groupings often correspond to
what people may think the XML equivalent of the OO people's
appropriation
of Alexandar's patterns are.

3) The third is my schema language and tools: Schematron, which was
designed
to support patterns. The current design only allows labelling of found
structures
as patterns rather than specification of patterns in the abstract (that
is possible
to implement, but a long way off: as long as we are all fixated on
grammars or
classes or other implementation/modeling paradigms there is little
chance of
stepping back for a more general view).

Available at: http://www.ascc.net/xml/schematron/schematron.html
There is an interview on schematron with XML-DEV regular Simon
St.Laurent at: http://www.xmlhack.com/read.php?item=121


If anyone is interested in persuing patterns further, please do any of
the following:
    * email me or this list
    *
    * read the HTML page
    * buy or read my book!
    * read "the Gang of Four" pattern books from Addison Wesley, and
also the
    excellent "Anti-Patterns" book from John Wiley
    * you can find patterns tacetly lurking in most good SGML/XML books
(that
are not just introductions) such as Eve Maler's or Dave Megginson's
books.

Rick Jelliffe

P.S. In case this post is lost, Toivo Lainevool is following on from a
post of Don Park
on XML-DEV which mentions three "preliminary XML design patterns" to aid
thinking about XML:
    * pockets ( elements that could provide an equivalent information
set as
    the element/attribute distinction provides in normal XML)
    * parental guidence (elements that could provide an equivalent
information
    set as provided by attributes that apply to child elements)
    * road signs (elements that could provide an equivalent information
set
    to attributes or PIs (unclear, sorry))




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS