Re: request as data source in transformation?

I sympathize with the desire to try to get agreement on the general
principle first before venturing into the design of a specific syntax.

But at the moment, I have to say I do not understand anything about this
proposal, and I suspect that part of the reason for my incomprehension
is that I need concrete examples.  A syntax proposal is not required for
examples, of course:  examples can be described in prose, although they
can quickly become very long.

Other people seem not to be suffering from the same level of
incomprehension as me -- perhaps it's just that I don't live in the web
application world -- so I wonder:  can anyone else help Sasha (and me)
out by explaining in a little more detail, for a bear of very little
brain, why the HTTP Client spec won't work here?

Thanks to anyone who can help.

Michael


Sasha Firsov <suns@firsov.net> writes:

> I am trying to avoid the exact syntax proposal at this stage. We need
> to have an agreement on including DAL as one of the essential pieces
> of XSLT first.  If we treat XSLT as an application transformation
> pipeline engine, then it would be a natural choice. If XSLT is treated
> just as a template for data feed, there is no reason to continue.
>
> The XSLT syntax needs some semantic adjustments in order to be
> efficient as an application transformation engine. We would discuss
> those aspects separately. It would be tied to request syntax.
>
> The semantic meaning of data source pipeline would include:
> * data source definition, with url, methods, etc.
> * request object. 
> * response object
>
> associated flows
> * data source preparation ( fill in the dynamic data as result of transformation )
> * triggering request
> * response processing
> * response data use in general document transformation 
> Each flow would have its own syntax and ability to associate its own transformation rules. The syntax for most flows fits into XSLT 3.0, the objects can(should be?) expressed via their own DTD.
> -s
>
> On Tue, Dec 20, 2022 at 3:57 PM Christian Grün <cg@basex.org> wrote:
>
>  Hi Sasha,
>
>  Do you have some idea how the declarative syntax should look like? Should it be XSLT-only or be added to XPath?
>
>  Best,
>  Christian
>
>  Am 21.12.2022 00:16 schrieb Sasha Firsov <suns@firsov.net>:
>
>  Christian, et al, 
>  while HTTP Client v2 as part of EXPath has a complete sense on its own, in order to be efficient in the transformation pipeline by Declarative Web Application, the declarative syntax for
>  request/response is a must. Without declarative XSLT syntax following transformation rules would be tough to layer. 
>
>  In addition to request preparation as part of transformation, there are many other use cases which are essential part of web application:
>  * pre-request authentication( tokens of all kinds, etc. )
>  * request payload validation to match the expected schema.
>  * response validation against expected by client schemas
>  * variations and error handling with potential re-try.
>  * response integrity validation
>   
>  Note, all ^^ are meant to be executed by transformation pipeline, i.e. have to be expressed via XSLT syntax. Outside of XPath where those layers are not meant to be primarily defined.
>  The execution environment would be triggering layers depending on runtime configuration. Schema Validators have to be run only once when the service or client code is changed, session
>  token has to be re-validated only if the previous is expired, etc. That fits into the request pipeline as XSLT concept but not into XPath.
>
>  -s
>  PS. Can we agree that all cases ^^ have to be supported as declaratively as via scripting languages ( XPath and JS )?
>
>  On Tue, Dec 20, 2022 at 2:18 AM Christian Grün <cg@basex.org> wrote:
>
>  Hi Sasha, 
>
>  An EXPath module exists for sending HTTP Requests, it's called HTTP Client Module:
>
>  http://expath.org/spec/http-client
>
>  Together with Adam, we've done some work on a new version:
>
>  http://expath.github.io/expath-cg/specs/http-client-2/
>
>  The general question may be which features should be part of the core language or made available externally, as e.g. discussed here:
>
>  https://github.com/qt4cg/qtspecs/issues/274
>
>  Best,
>  Christian
>
>  Am 20.12.2022 05:28 schrieb Sasha Firsov <suns@firsov.net>:
>
>  Dear XSLT forum, this is a teaser for an architectural kind of discussion, not a syntax.  
>
>  Rather than reference to external documents in XPath/ #XSLT, the Declarative Web Application needs a concept of Request as valid data feed. 
>
>  The data source reference the object is a result of transformation with 
>  * url
>  * headers
>  * http method
>  * custom payload
>  * schema of data in response
>
>  This data source then could be used as input parameter for following XSLT transformation via XPath. The data source is just a definition which would be resolved to live HTTP
>  request only when it is actually used in transformation. 
>
>  The request would produce the Response object with access to
>  * response HTTP code( 200 for normal, 4xxx, 5xxx errors, etc. )
>  * http headers
>  * data. The data reading would be immediate when no schema defined, or triggered dynamically when data access needed by transformation/selectors in case the schema is
>  available.
>
>  -s
>  PS. The Declarative Web Application stack manifest and proposal is still in baking and data access layer based on XSLT transformation pipeline is a part of it.


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Tuesday, 3 January 2023 23:55:27 UTC