xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
Subject Re: XSP Spec
Date Wed, 08 Nov 2000 14:41:27 GMT

Matt Sergeant wrote:

> xsp:page (language => '(Java|Perl)', indent-result => '(Yes|No)')
>   reason: doesn't really do anything, except maybe set a few flags
>   context: /xsp:page
>   results: class framework

Imo, this tag should be deprecated, as explained in a separate post.
I agree completely with Matt: it does nothing. Its flag-setting role
can be easily achieved by [root-level] attributes in the xsp namespace.

>
> xsp:structure
>   I'd like someone else to fill this in.

So far, this top-level element has been used only to enclose <xsp:include>
(e.g. Java import) directives. As explained in the post proposing <xsp:page>
deprecation, this element could be redefined to enclose both  import
directives and class-level logic. Example:

  <page xmlns:xsp="http://apache.org/xsp">
    <xsp:structure>
      <xsp:import>java.text.SimpleDateFormat</xsp:import>
    <xsp:logic>
      private static String systemDate(String mask) {
         return new SimpleDateFormat(mask).format(new Date());
     }
    </xsp:logic>
  </xsp:structure>
  </page>

The reason why I propose enclosing <xsp:logic> inside <xsp:structure>
is because the previous mechanism to define class-level logic was,
simply, to place the corresponding <xsp:logic> element(s) right below
the (now deprecated) <xsp:page> element. In absence of an XSP
root element (and given that <xsp:structure> is a _top-level_ tag),
it seems only right to use <xsp:structure> for this purpose. What do
you guys think?

> xsp:include
>   reason: To "include" external modules
>   context: /xsp:page/
>   results: language dependant

Note, in the previous example,  that here we're replacing <xsp:include> by
<xsp:import>.

The "import" directive has a external module _reference_ semantics, not
generation-time inclusion semantics. Note that JSP uses the <%include%>
directive with generation-time inclusion semantics.

An open question: should XSP provide a generation-time inclusion
mechanism? Things to consider: XInclude, external entities and
logicsheets...

>
> xsp:content

This tag provides a way of inlining XML content inside <xsp:logic> without
closing and reopening the logic block. It has been repeatedly suggested  we
should deprecated, but I feel it has a rightful place under the sun. The only

limitation: it's vali _only_ inside an <xsp:logic> element.

>
> xsp:logic
>   reason: provides a placeholder for class level code
>   context: /xsp:page/xsp:structure
>   results: probably nothing - code gets output verbatim (after processing)

According to my proposal, <xsp:logic> does not provide a placeholder for
_class-level_ code but for "regular" inlined code.

Implicit in XSP's code generation mechanism (for Java and other OO languages,

at least) is the notion that the input document is to be translated into XML
generation
code _inside a method body_  only. <xsp:logic> blocks augment this method
body.

>
> xsp:element (name => element_name)
>   reason: generate an element
>   context: ???
>   results: ??? - need more info on what Cocoon does here, obviously it may
> have to wait until we have a name and all attributes...

<xsp:element> has semantics similar to that of XSLT's <xsl:element> tag:
it's meant to dynamically build an element whose tag name and/or attribute
name/values are not know at generation time.

This tag has been the object of a debate because it appears to be redundant
and overlapping with respect to XSLT.  Note, however, that XSP is a
_code generation_ language, not a transformation one. Where <xsl:element>
says "insert an element here", XSP says "generate code to dynamically
build an element here".

Currently, <xsp:page> lacks namespace support and this must be fixed asap.
In the DOM version, this problem can be easily solved by concatenating the
namespace _prefix_ and the tag name, so nobody has complained so far.

A more rigurous definition calls the explicit and separate definition of the
tag name and the namespace's _uri_ (as opposed to its prefix):

    <xsp:element>
      <xsp:name>. . .>/xsp:name>
      <xsp:namespace-uri>. . .</xsp:namespace>
      . . .
  </xsp:element>


>
> xsp:attribute (name => attribute_name)
>   reason: generate an attribute
>   context: xsp:element/xsp:attribute
>   results: ??? ditto above

Same as above: <xsp:attribute> provides a means to dynamically build
an attribute when its name and/or value are not known at generation
time.

Btw, both <xsp:element> and <xsp:attribute> names can be defined
by means of a "name" attribute or a nested <xsp:name> element:

    <xsp:element name="constant-name">. . .</xsp:element>

   <xsp:element>
      <xsp:name><xsp:expr>myTagName</xsp:expr></xsp:name>
     . . .
   </xsp:element>

>
> xsp:pi
>   reason: generate a processing instruction
>   context: anywhere?
>   results: a processing_instruction event - need more details
> regarding the target/data in the PI here...

Consistency with related languages (XSLT in this case) would require
that we rename this element to <xsp:processing-instruction>.

Target and data are specified in the usual way: as either attributes
to the XSP tag when their value is known at generation time or as
nested elements when their value is to be computed at request time.

>
> xsp:comment
>   reason: generate a comment
>   context: anywhere?
>   results: a comment event - need more details regarding the contents of
> the comment here...

I feel the current definition is appropriate...

>
> xsp:text
>   reason: generate a text node
>   context: xsp:element/xsp:text ???
>   results: a characters event - need more details regarding the value of
> the characters for the event.

<xsp:text> has never been part of the "official" XSP language definition.
It's a hack used internally by Cocoon's XSP processor to enclose strings
escaped according to the rules of the target progamming language.

Its semantics are _totally_ unrelated to those of XSLT's <xsl:text>
tag.

The current string enconding mechanism should _not_ use the XSP
namespace.

>
> xsp:expr
>   reason: generate a string using code
>   context: ???
>   results: A string or a text event depending on context?

<xsp:expr> produces either an [object] _expression_ (not necessarily a
String)
or a character event depending on context..

When  <xsp:expr> is enclosed in another XSP tag (except <xsp:content>), it's
replaced by the code it contains. Otherwise it should be treated as a text
node
and, therefore, coerced to String to be output through a characters SAX
event.




Mime
View raw message