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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Namespaces and XSLT simplified syntax

[ Lists Home | Date Index | Thread Index ]
  • From: Dan Vint <dvint@slip.net>
  • To: "Steve Muench" <smuench@us.oracle.com>, <xsl-list@mulberrytech.com>, <xml-dev@ic.ac.uk>
  • Date: Mon, 10 Jan 2000 08:26:09 -0500

>From the answers I've seen it appears the simplified method has its
restrictions to 
make it simple, so with that can I infer that it is also possible to have a
stylesheet
 setup similar to the simplified model that has the full capability of a
standalone stylesheet. 

The reason why I ask, is when you look at extension elements,
forwards-compatible 
processing, exclude-result-prefixes the spec will list xsl:stylesheet and
literal result 
elements with the appropriate attributes prefixed with xsl: .


This seems to imply a full featured version of a stylesheet being
intermixed in the 
source document, but not embedded where the xsl:stylesheet element is used.


Now I don't know what the value of such a thing would be (one less file to
open 
maybe) I'm just trying to understand all the "rules" in the specification.

..dan

At 07:39 PM 1/9/00 -0800, Steve Muench wrote:
>Dan,
>
>Using the simple form gives up some features to
>achieve simplicity of representation for people
>who want to continue using their existing HTML
>editors to edit their "HTML page with data
>plugged in" as they learn to exploit the basics
>of XSLT.
>
>As you've encountered, the key limitation
>is that you cannot use "top-level" XSLT-namespace
>elements like:
>
>  xsl:import
>  xsl:include
>  xsl:strip-space
>  xsl:preserve-space
>  xsl:output
>  xsl:key
>  xsl:decimal-format
>  xsl:namespace-alias
>  xsl:attribute-set
>  xsl:param
>
>in a "simple form" stylesheet. The feeling in
>the XSL Working Group was, if someone began
>to "discover" the need for these facilities,
>then they were venturing beyond the "simple-case"
>stage, and at that point we could assume they
>were mentally "ready" to learn about an
>enclosing <xsl:stylesheet> element and what
><xsl:template> is used for.
>
>=== Some Background ===
>
>The "simple form" of an XSLT stylesheet -- known in
>the spec as "Literal Result Element as Stylesheet"
>http://www.w3.org/TR/xslt#result-element-stylesheet --
>was conceived as a mechanism to allow someone familiar
>with HTML to continue to use their familiar HTML
>editing tools to work on stylesheets that only
>need a single, root template. The feature was
>designed as a smooth-slope introduction capability
>to be able to help people who knew HTML begin to
>use XSLT without understanding the Spec cover to cover.
>
>One very common case that the "simple form" caters to,
>is the one where someone is formatting database
>query results into an HTML page. Many Ecommerce apps
>are doing this, making use of XML/XSLT, a stylesheet
>like:
>
> > xsl:version="1.0"> > > > > > 
> > > > > 
> > > >
>
>This stylesheet can still edited using FrontPage,
>DreamWeaver, etc. With the simple form, once you
>teach HTML-savvy people that they:
>
>  (1) Add an XSLT namespace declaration and
>      xsl:version="1.0" to their element, and > (2) Combine for looping
and > to "plug in" dynamic data > (3) Use /a/b/c "directory-like" notation
to refer > to elements in the source document (the way > I explain the
basics of XPath to beginners) > >Then they can begin to get productive
without >having to understand the XSLT spec cover to cover.
>_________________________________________________________ >Steve Muench,
Consulting Product Manager & XML Evangelist >Business Components for Java
Development Team >http://technet.oracle.com/tech/java
>http://technet.oracle.com/tech/xml >----- Original Message ----- >From:
"Dan Vint" >To: ; >Sent: Sunday, January 09, 2000 1:13 PM >Subject:
Namespaces and XSLT simplified syntax > > >| Here is yet another question
on namespaces that I came up with after >looking at >| the XSLT
specification and its simplified syntax. And let me go a little >| further
back to HyTime. >| >| I understand (sort of) how an attribute on any'ol
element can be pointed >to or >| mapped to an attribute in a different
namespace by using a prefix to the >| attribute name as shown here: >| >|
>| xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >|
xmlns="http://www.w3.org/TR/xhtml1/strict"> >| >| I also thought that
architectural forms from HyTime allowed me to say this >| element of
whatever name I specify should be treated like this other >element >| over
here - I don't remember what the syntax is for it by I have sort of >|
thought of namespaces as being related to this functionality. >| >| What
I'm looking for is the syntax in XML/namespaces that would allow me >to say
>| (in the above example) >| that my element should be treated as and thus
>allow me >| to use content from the HTML content model for the element and
the >| content for the . Of course I would use the namespace >prefix >| for
those elements as well. >| >| Is there a method for aliasing two elements
like this? >| >| There seems to be an indication that an xsl:stylesheet
modeled style sheet >| should work the same as a stylesheet somehow being
managed in a literal >result >| element (see the requirements for the
version and other attributes in this >| case), but then the only example
shown in the spec (and the only model >that I >| can think of) seems to
fall squarely into the simplified syntax model >which >| then has the
restrictions about only using instruction elements - am I >just >| mixing
these two ideas up? >| >| Is the simplified syntax just a stricter set of
requirements, but the more >| general form of using a literal result
element as the document root and >| spreading xsl:xxxx top-level elements
is allowed in the more general case? >| >| ..dan >| >|
--------------------------------------------------------------------------
>- >| Danny Vint http://www.dvint.com >| Author: SGML at Work
http://www.slip.net/~dvint/pubs/sgmlatwork.shtml >| >mailto:dvint@slip.net
>| >| Calian Voice:804-975-3482 >| mailto:d.vint@calian.com >|
Charlottesville, VA Office http://www.calian.com >| >| >| XSL-List info and
archive: http://www.mulberrytech.com/xsl/xsl-list >| > > >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) > 

---------------------------------------------------------------------------
Danny Vint                                       http://www.dvint.com
Author: SGML at Work   	http://www.slip.net/~dvint/pubs/sgmlatwork.shtml 
                                                       mailto:dvint@slip.net
    
Calian                                              Voice:804-975-3482
mailto:d.vint@calian.com
Charlottesville, VA Office                http://www.calian.com              


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