Re: The first five minutes ... a thought experiment (long)

On 20 févr. 2014, at 14:46, Alex Milowski <alex@milowski.com> wrote:

> On Thu, Feb 20, 2014 at 12:45 PM, Romain Deltour <rdeltour@gmail.com> wrote:
>> On 20 févr. 2014, at 13:07, Alex Milowski <alex@milowski.com> wrote:
>> 
>>> Using XPath for ports is fraught with issues.  How do you do the
>>> static analysis to figure out what is connected to what?
>> 
>> See my proposal in the thread "an idea: ports == options".
> 
> I am referring to that proposal as well.

OK. In that proposal I suggest that readable ports can be declaratively assigned to variables added to the in-scope bindings. This declaration is explicit, static info and can be relied on for static analysis.

> 
>> 
>> The req isn't saying either that XDM is not an option. I think XDM should be carefully considered.
>> 
>> Saying that data flowing through a pipeline is xs:hexBinary or xs:base64Binary does not mean that the data *MUST* be serialized until it's explicitly asked (as a string or document node). Implementations could very well use a stream handle underneath.
> 
> Hmm, ... not sure that's a great solution.  Primarily, the concept of
> the "binary is a document" is lost by just using arbitrary values.

I’m not sure I understand what you mean by that.

> The "1" and "(1 2 3)" become documents without any associated media
> type.
> 
>> 
>> Another option is the "resource manager" approach, where you could represent non-XML content by reference (URI). Again, this can be compatible with an XDM approach.
> 
> That has been considered in the past but the non-uniformity of making
> binaries somehow second-class objects makes that solution less
> attractive.
> 
>> 
>> I don't really buy the "then use XQuery" argument.
>> 
> 
> My point simple is you can write a XQuery program to process sequences
> of items as composed functions.  That approach tends to have its own
> set of problems which include the ability for someone to understand
> the code.  The approach where steps just operate on inputs that are
> sequences of items and produce a tuple of sequences items is just as
> fraught with issues of complexity.  

An approach where step operate on XDM input/output does not imply that steps are used as composed functions like one would do in XQuery. XProc’s nature of a workflow description language is orthogonal to what flows in/out. The “programming” paradigm between XProc and XQuery is totally different, which is why I don’t really understand the comparison.


> In particular, I question the
> streaming capabilities of such an approach as the "XPath expression"
> assumption requires that you have the complete value in some sense
> (e.g. you have the complete set of documents from the preceding step
> if it produced more than one document).

OK, that’s a very good point.

For one thing, it’s possible to make non-streamable XProc in v1 already.
Another thing is that all the work on XQuery and XSLT streamability may be used here to analyze whether an XPath expression is streamable.

> 
> There is also useful distinction in steps that operate on inputs and
> are controlled by options.  Conceptually, this may be easier to
> understand for some users.  If you look through our inventory of
> steps, options universally have simple values.  There are only a few
> situations (e.g. parameters) where you'd like a non-simple value like
> a map.

Yeah, and to be honest I can see value in that distinction.

That said, looking at the inventory of v1 steps is a red herring. Of course options universally have simple values, that cannot be otherwise. Or it would be hell too complicated to parse.
But, if v2 allows any XDM in options (MUST req 2.5), that could change, right ? An option can theoretically be a sequence of documents. Or are you limiting it to sequence of atomic types ?

In any case, the idea of being able to access readable ports from the XPath context by explicitly-declared in-scope bindings stands, regardless of whether options and ports are different things and regardless of whether any XDM is allowed to flow.

Romain.

> 
> 
> 
> -- 
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
> 
> Bertrand Russell in a footnote of Principles of Mathematics
>

Received on Thursday, 20 February 2014 14:23:54 UTC