Re: working draft updated

I'm not quite sure I understood the grounds of your objection Petr.
What use cases require knowledge of buffers at compile time? I know of none.
To me the semantical difference as such is an irrelevant argument as 
there is no right or wrong answer here.

Thinking of all this again I'd have to reiterate the whole idea 
(slightly differently though).

Lets for a moment imagine that buffers are just another URI protocol type.
They would be recognized by an URI in the format "buffer://<name>".

Lets imagine also that stx:xxx-buffer and stx:buffer are removed from 
the language specification
(assuming that buffers are instantiated by implicit reference rather 
than explicit keyword).

Lets assume also that "buffer:" protocol is optionally supported by the 
processors
(pretty much like filters are an optional yet have a note on them in the 
language specification).

Now, what would all this lead us to:

- "@href" in stx:xxx-document can recognize "buffer://<name>" URIs thus 
directing input/output from/into buffers.

- core (mandatory) language would deal only with "pure" transformations 
(as you call them). I assume you mean by that single-pass,
endless input streams of data, no (sub-)documents in-memory handling.

- extended support for buffer-protocol would allow for multi-pass, 
sub-documents in-memory transformations.

- extended support for filters would allow for XDM sub-document 
transformations and transformation pipelining.

This covers all existing functionality without omitting anything. Well, 
not quite ;) clear/append buffers is not addressed here ...

Nikolai

ext Petr Cimprich wrote:
> Hi Nikolay,
>
> Nikolay Fiykov wrote:
> > My impression is that we _can_ replace buffers with uri protocols, 
> > for example: "buffer://<name>" instead of "buffer(<name>)".
> >
> > IMHO, this has five distinct advantages over current way:
> >
> > - Language would be simplified and less controversial:
> >    - no stx:xxx-buffer anymore (because stx:xxx-document would cover 
> > them)
>
> I'm not quite sure if this is really a good thing. With a special 
> instruction for buffers it is clear whether buffers will be used or 
> not in the compile time. With the buffer:// scheme and AVTs you can't 
> look at an stxsheet and tell whether the transformation will be "pure" 
> streaming or it will need buffers. This is my main objection.
>
> >    - @filter-src would feature only one notation filter-src="<uri>" 
> > (instead of current dual mode syntax)
> >    - all stx:process-xxx would operate with documents or buffers 
> > flawlessly
> We would only unify stx:process-document and stx:process-buffer. The 
> rest (stx:process-children, stx:process-attributes, 
> stx:process-siblings, stx:process-self) work with the current stream 
> only anyway. May I'm missing what do you mean.
> > - Processors would be simplified too:
> >    - single data model based on streams only (regardless if they 
> > would be buffered in memory or coming from external socket/file)
> >    - generic handling for all stx:process-xxx methods (regardless if 
> > dealing with buffers or other sources)
>
> I use the same stream data model in XML::STX already regardless on 
> syntax. Internally, I treat buffers as a special scheme and I guess it 
> will be similar in Joost. Thus I think we only discuss syntax and its 
> implications.
>
> Petr