Wendell P.,
Thanks much for your detailed info.

I will pass this on to my friend.

Good analogy.

Mike Ferrando
Library Technician
Library of Congress
Washington, DC
202-707-4454

--- Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:

> Mike,
> 
> Although it's theoretically possible to code XSLT with XMetaL, one
> wouldn't 
> ordinarily do this.
> 
> The main reason for this is that, as a structured editor, XMetaL is
> 
> dependent on a DTD (or schema) to inform it of legal document
> structures 
> for a given instance.
> 
> There is no DTD for XSLT, and there really can't be, since any
> stylesheet 
> may contain arbitrary literal result elements, which means a DTD
> for XSLT 
> would have to include all possible XML elements, in all possible 
> arrangements. Since XML element (and attribute) names are not
> limited in 
> length, this is an unbounded set.
> 
> A partial DTD for XSLT 1.0, in which LREs are not accounted for
> except by 
> placeholders, is actually available (published as an appendix to
> the spec), 
> although non-normative. On this basis it might conceivably be
> possible to 
> write a DTD to describe, say, XSLT stylesheets that generate HTML.
> (Or 
> alternatively, one might prohibit LREs in one's stylesheets and use
> only 
> xsl:element and xsl:attribute instructions for generating nodes. I
> have 
> even seen this approach taken with Emacs, though not recently,
> since we 
> have had decent tools including XSLT IDEs for Emacs.) But even this
> would 
> be a poor fit, since the semantics expressible in DTDs do not cover
> the 
> actual constraints over XSLT. For example, a DTD by itself could
> not tell 
> the difference between an XPath expression and just any string, in
> an XSLT 
> "select" attribute value. A stylesheet containing an illegal XPath 
> expression is formally not XSLT at all, since it can't be compiled.
> But DTD 
> validation on its own can't distinguish this class of documents
> from actual 
> stylesheets.
> 
> Current versions of XMetaL also support schema validation in lieu
> of DTDs, 
> but the same problems apply there -- not as severely, but to the
> same 
> practical effect.
> 
> What all this argues is that XSLT not be considered to be just any
> XML 
> document, usefully editable by any XML editor. (Even if this can be
> done in 
> a pinch: and indeed, XMetaL does have a "well-formed only" mode,
> though 
> this is not its strength.)
> 
> Accordingly, we have a healthy market for tools, such as oXygen
> (which 
> Bruce mentioned), ActiveState Komodo or XMLSpy. Given how much of a
> range 
> of choices one has here (including at the free end), using XMetaL
> would 
> seem rather, um, twisted. Like baking a cake in a fireplace. It can
> be 
> done, sort of: but it's much much easier in a proper oven.
> 
> Cheers,
> Wendell
> 
> At 01:32 PM 6/3/2005, you wrote:
> >Friends,
> >I was recently asked about using XMetal with XSLT.
> >
> >I don't use XMetal.
> >
> >However, maybe there are some out there that could give me the
> >low-down on the good, bad or ugly XSLT "features".
> 
> 
>
======================================================================
> Wendell Piez                           
> mailto:wapiez@xxxxxxxxxxxxxxxx
> 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
>
======================================================================
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com