2.6 patterns: let's try variations on the XML syntax

This issue is a tough one.  I'm not surprised that people complained about
using XML for patterns (in the original proposal); it *is* somewhat
awkward.  But it is exactly on the tough questions where the design
principles are most important.
	XSL should be expressed in XML syntax.
	XSL stylesheets should be human-readable and reasonably clear.
	Terseness in XSL markup is of minimal importance.

Please don't stop halfway.  Complaints about the syntax being verbose are
opportunities for articulating the benefits of XML.  If nothing else,
developers are more than welcome to create text-oriented authoring tools
that support any syntax they desire.  All we ask is for XML to be the
neutral -- and universal -- interchange format for all sorts of data; not
least, XSL.

...

Maybe the solution lies in finding an easier XML syntax rather than
switching to a non-XML syntax.  I have a proposal (in 2 variations); maybe
others can suggest additional alternatives.

Thanks to XSL's use of namespaces (kudos!), normal tags can be used as part
of templates; why not use them in patterns?  The stylesheet could show the
exact tags that are to be matched; there's no "translation" to <element
"..."> or "... / ...".  (I'm no expert here so let me know if I've missed
something obvious!)

<xsl:template>
	<xsl:match>
		<para></para>
	</xsl:match>

	<xsl:action>
		<fo:block font-size="10pt" space-before="12pt">
			<xsl:process-children/>
		</fo:block>
	</xsl:action>
</xsl:template>

I'm not sure if the <xsl:action> tags are a good idea; I was just striving
for balance.

Although it's a very minor point, including the start & end tag (e.g.
<para></para>) is a reminder that the action applies to the entire
contents; it can do any of: insert text or tags before the start tag,
process the contents, insert text or tags after the end tag.  But, if you
prefer something shorter and aren't bothered by turning tags that are
usually balanced into empty tags (or whatever the right term), there's a
simple variation:

	<xsl:match>
		<para/>
	</xsl:match>

...

An "or" is easy:

	<xsl:match>
		<emph></emph>
		<strong></strong>
	</xsl:match>

The "//" construct could be something like:

	<xsl:match>
		<para>
			<XSL:any>
				<changed></changed>
			</XSL:any>
		</para>
	</xsl:match>

More complex patterns are of course more complex (and my suggestions are
very tentative here).  As shown in the original proposal, there needs to be
a way to distinguish between the tag that is the target ("author" in this
case) and one or more tags that are just part of the test (the "book"
contains at least one "excerpt"); I decided that the test will be an xsl
tag not a literal tag:

	<xsl:match>
		<book>
			<xsl:test="at-least-one" tag="excerpt"/>
			<author xsl:test="contains" xsl:attribute="degree"></author>
		</book>
	</xsl:match>

...

I attempted to convert every example in the working draft.  You can view
either variation side-by-side against the WD examples:
	http://www.publishanywhere.com/xsl/patterns-as-xml-1a.html
	http://www.publishanywhere.com/xsl/patterns-as-xml-1b.html

If you don't have a wide monitor, or in case you want to use one of the
files as a starting point, I have them as plain text (no comparison),
starting with the excerpt from the working draft (with the whitespace
slightly modified, and one typo corrected):
	http://www.publishanywhere.com/xsl/patterns-wd.text
	http://www.publishanywhere.com/xsl/patterns-as-xml-1a.text
	http://www.publishanywhere.com/xsl/patterns-as-xml-1b.text

If I had planned ahead, I would have extracted the explanatory text along
with each example, but it's pretty easy to find things in the spec.

Feedback welcome!!!

Scott



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list