Re: Proposal: replace here documents with a component

Mmh, I understand that this adds some complexity to the language. 
However we do have "here documents" in XPL, and you wouldn't believe how 
often you use this functionality - once you have it! In particular, you 
start writing many short inline XSLT stylesheets, something you wouldn't 
do if you had to store them in separate documents. So I would dispute 
that this will be uncommon.

-Erik

Norman Walsh wrote:
 > I wouldn't dream of removing the functionality of "here documents",
 > but there's a balance to be made between simplicity and functionality
 > and I think we've got it wrong with respect to here documents in the
 > current draft.
 >
 > The fact that we have three ways to describe inputs, and the fact that
 > one of them (here documents) is very different from the other two
 > (attributes) makes the draft quite a bit more complicated.
 >
 > It also imposes (unnecessary, IMHO) constraints on the design of the
 > language. Consider the current draft's position on "choose" as opposed
 > to "for-each". Because we put the context attributes directly on the
 > "choose" element, you can't use a here document for choose. Because we
 > used a "declare-input" for for-each, you can.
 >
 > Bleh.
 >
 > I propose a standard "p:document" component that has no inputs and
 > returns its content as a document instead.
 >
 > Instead of writing:
 >
 >   <p:step name="xform" type="xslt">
 >     <p:input port="document">
 >       <div xmlns="...">
 >         <p>some txt</p>
 >       </div>
 >     </p:input>
 >     <p:input port="stylesheet" href="something.xsl"/>
 >   </p:step>
 >
 > you'd write:
 >
 >   <p:document name="htmlfrag">
 >     <div xmlns="...">
 >       <p>some txt</p>
 >     </div>
 >   </p:document>
 >
 >   <p:step name="xform" type="xslt">
 >     <p:input step="htmlfrag" port="result"/>
 >     <p:input port="stylesheet" href="something.xsl"/>
 >   </p:step>
 >
 > I think that here documents are relatively uncommon and I don't think
 > this is a significant burden on authors.
 >
 > It has two additional benefits:
 >
 > 1. The step is considerably shorter and simpler and, as a consequence,
 >    I think it's easier to understand.
 > 2. The content of the here document becomes reusable.
 >
 >                                         Be seeing you,
 >                                           norm
 >


-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Thursday, 21 September 2006 14:24:04 UTC