This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: XSLT Documentation (Was: RE: How is this part of the XSLT specification to be interpreted?)
- To: xsl-list at mulberrytech dot com
- Subject: RE: XSLT Documentation (Was: RE: How is this part of the XSLT specification to be interpreted?)
- From: Wendell Piez <wapiez at mulberrytech dot com>
- Date: Thu, 22 Jun 2000 12:06:59 +0100
- Reply-To: xsl-list at mulberrytech dot com
This is an interesting thread.
My comments in line. Thanks to Dave for starting to formalize this. Dave,
does this mean you are collecting a proposed features list? Are there any
formal requirements stipulated?
At 01:21 PM 6/22/00 +0100, DaveP wrote:
>Off the top of my head *some* of the key things to know about a stylesheet
>might be.
One might also want to know things about particular templates and about
particular constructions in templates. (Dave might have meant that.)
>1.
>prime purpose of a simple template
>e.g. Transforms element x into y/z
>
>2. Exception processing
>source document element a is processed within template for
>element b because....
Could be generalized to include explanations of conditional processing logic.
Conditional processing happens (at least) two ways: through template
matching (e.g match="p[@show='extralarge']") and through <xsl:if>/<xsl:choose>
>3. Use of global variables.
>E.g. variable $root holds the content of document(....)
Remember the logic of parameters and how/why they get passed, too.
And this folds into 1. when we start talking about fancy recursive templates.
>4. Interpretation of any special select patterns.
> E.g. this template selects all list items and does x.
Grouping/sorting logic could fall into this category.
I'm not sure there's a clear typing evident from these kinds of
explanations. There do seem to be levels of explanation -- explanations at
the stylesheet level, at the template level, within the template, and
perhaps of particular attribute values as well (such as funky select
attributes). I do think some clarification of requirements would help
direct a design.
Another question is how this tag structure should be validated. Clearly a
DTD isn't going to get far. Schematron?
Heh. This could be cool.
--Wendell
======================================================================
Wendell Piez mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list