Re: Proposal: replace here documents with a component

/ Alex Milowski <alex@milowski.org> 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,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.