Re: “Packaging”

Note related issue 366:
https://github.com/qt4cg/qtspecs/issues/366


On Fri, Nov 10, 2023 at 12:13 PM Christian Grün <cg@basex.org> wrote:

> Hi Norm,
>
> I think I agree with all your observations: It feels essential to have a
> unified packaging mechanism; both implementors, contributors and developers
> would benefit a lot from it. FunctX I believe is a great example for that,
> although it’s “just a library” and limited in is scope, but it has been
> used a lot with different processors (as far as I can judge). The EXPath
> Packaging was at least an honorable attempt. I felt the main deficiency was
> that every implementation used/embedded it differently. Next, I remember
> the interesting qtspecs discussion on that topic [1].
>
> I also agree it feels out of scope to spend really much time on it in our
> group, so I definitely appreciate the intent to achieve a lot with little
> effort :)
>
> Again it's the XQuery prospective I advocate, and the easiest approach
> that I can imagine would be to:
>
> • have a central repository for downloading modules with a given path and
> • address these modules with the existing XQuery “import module namespace
> 'xyz';” statement.
> • If an implementation exists for the URI in the processor, or if the
> module has already been downloaded, the repository access can be skipped.
>
> That's it. Basically. But of course some challenges start just here:
>
> • Do we only want to support XQuery library modules?
> • If we support other languages (such as Java/JavaScript code, or any
> other language than can be run by the invoking processors), how do we
> define entry points (function signatures)? The approach we chose for “Java
> Modules” would probably not be generic enough [2].
> • How can specific versions of the module be addressed? Possibly with an
> optional ‘version' query parameter in the module URI?
> • Or would it be better to define dependencies outside the code (see Maven
> and similar)?
>
> And I have no idea how that would match with XSLT…
>
> My two cents,
> Christian
>
> [1] https://github.com/qt4cg/qtspecs/issues/274
> [2] https://docs.basex.org/wiki/Repository#Java
>
>
>
> Am 10.11.2023 12:13 schrieb Norm Tovey-Walsh <norm@saxonica.com>:
>
> Hello,
>
> At Declarative Amsterdam this year, Adam Retter gave a compelling talk
> (EXPath Pkg Version 2) about the possibility of doing some sort of
> packaging work.
>
> We’ve talked about this a few times, in at least a couple of different
> contexts. I think we’d all agree that Maven, NuGet, NPM, pypi, etc. are
> a significant part of their respective communities.
>
> It would be good if we had something like that too. It’s a very large
> undertaking and solving that problem is absolutely out-of-scope for us.
>
> However…
>
> Could we spec out the bare minimum needed to support some sort of
> packaging for XQuery and XSLT? (This is related to, but probably
> distinct from xsl:package packages; the fact that there’s going to be
> overlap there is just an unfortunate reality.)
>
> I’m motivated to bring this up now both because it would be better to
> have the hooks in place if/when some future packaging standard takes
> off, and because we might allow vendors to leverage the mechanism in
> non-standard ways in the short term.
>
> I’m also thinking about all of the functions we’re seeing proposed. I
> fear the list of useful functions we could standardize is endless and
> we’ve already reached a point where it would be challenging to
> articulate a principled account of when we do or do not standardize
> fn:usefulthing.
>
> My naïve, I’ve spent a whole 10 minutes thinking about this, story goes
> something like this:
>
> Suppose a query could begin with
>
>    some-syntax-for-packages "array-extensions"
>
> and that would make a family of array extension functions available
> (perhaps even in the fn: namespace) or
>
>   <xsl:some-syntax-for-packages module="cryptography"/>
>
> and that would make a family of cryptographic functions available.
>
> Vendors could roll their own with the expectation that when an
> interoperable packaging standard is available, they’ll support that too.
>
> I dunno. But it feels like we’ll regret it if we don’t make the hooks
> available.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
>
>

-- 
Joel Kalvesmaki
kalvesmaki.com