xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject Re: XSP Spec
Date Wed, 08 Nov 2000 17:14:01 GMT
On Wed, 8 Nov 2000, Ricardo Rocha wrote:

> 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.

Deprecated but still implemented, or deprecated and removed?

> 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?

I'm not sure... Seems like it could be implcit by the presence of
xsp:logic (or other tags) to me... But then Java is funny about where you
can define functions and things, unlike Perl, so it might make it harder
to process without it.

> > 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>.

Yes... Replace or add xsp:import as well?

> 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...

No. What we have will do just fine IMO.

> >
> > 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.

Why is it needed? Surely if you start seeing XML elements inside
<xsp:logic> they just fire off SAX events (or call out to whatever they
are supposed to do if they implement some logic)?

> >
> > 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.

OK, so the context above is incorrect.

> 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>

I'd rather not go that way - can't we just work like XSLT - where
namespaces have to be defined in the document (and yet are valid inside of
XPath too) ? I can't see any use for <xsp:namespace> - dynamically
declaring a namespace seems bad to me...

> > 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>

OK, so how does this work with SAX then? What do you wait for, before
firing the start_element SAX event (because obviously you need the element
name and all attributes to pass to the event)? Bear in mind that AxKit's
XSP->Perl processor is not XSLT based, it is SAX based, so it can't just
do tree logic like forward looks (well, it could, but I'd rather not, as
that is a lot of work).

> > 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>.

Ugh... :-)

Do we have to be consistent? Or maybe provide both...

> 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.

That seems consistent with <xsp:element>, but could you share what the
tags and attributes are please :-)

> > 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.

Could you go into a little more detail here?

> Its semantics are _totally_ unrelated to those of XSLT's <xsl:text>
> tag.
> The current string enconding mechanism should _not_ use the XSP
> namespace.

OK, so we remove it from the spec?

> > 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..

Isn't it coerced into a string regardless though?

> 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.


I'm thinking of setting up a Wiki to make editing this spec easier for
us. Any thoughts on that?


    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
    //  \\

View raw message