Re: Proposal: replace here documents with a component

/ Alex Milowski <> was heard to say:
| OK.  Except now you are computing an optimization for something was
| easily known before.  I could say the exact opposite in that you
| can easily recognize a here document and fabricate a step for it.

My argument against "here documents" *is about the syntax*, not the
semantics. So saying that I could fabricate the step automatically is
both true and not the point.

| Personally, I think this is far less usable than just putting the
| document where you need it.
| All this doesn't preclude the need for a "document" component.  That
| component is necessary for inputs that are shared.
| The canonical use case here is the XSLT transform being embedded
| in the pipeline itself.  What we have right now allows the XSLT step
| to be specified with one self-contained step (i.e. cut-n-paste is
| easy).  This proposal would mean you'd have two steps to do the
| exact same thing.

Like I said, I'm not sure I'm going to get consensus for this
proposal, but I think the cost of here documents in terms of spec
complexity outweighs their benefits.

                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Thursday, 21 September 2006 17:42:11 UTC