Prague meeting minutes

Hi,

Here are the "minutes" of the face-to-face meeting we had in Prague
yesterday, on Thu. 2015-02-12 (well, yes, it seems it is Friday 13...)
Rather than actual minutes, it is more a summary of the discussion
(rather than an actual transcript).

Summary of action items:

- Define a "standard" for each possibility ("if using XML, use a
  @name, or rather the name of the element", etc.)

- Creating a "good practice" or "design rules" or "editor notes"
  document or area on the website or on the wiki, to define such good
  practice as they are discuss in the course of action.

- Reply to John's email, describe what is above, and let him lead the
  particular discussion on options.

- Reply to John's email, explaining the above. (wrt XParse)

- Create a page (on the wiki, or on the website?) for "modules of
  interest", for ideas, or asking for help, or to centralize info
  about modules no one wrote a draft for, but we have discussed at
  some point...  In order to capture what has been said about
  potential modules.

- Add the "definition" for "current working directory" in 2.2, saying
  it's implementation-defined.

- Document this in a FAQ, or in an editorial rules page (the chair
  notes that no one pronounced the exact words "process document").

- Put a warning in the "dormant" draft, to tell they are parked for
  now, and looking for an editor.

- Ask Peter for status on Geo.

- Ask John for the status of Archive, and either park it (add a
  warning) or push it forward.

- Add a warning in the ZIP module (as being superseeded by the Archive
  module), depending on the answer of John wrt the status of Archive.

- Write tests to have enough coverage. (wrt HTTP Client)

- Write tests for the Packaging System.

- Add this to the page "modules of interest", created for "Schema
  access". (wrt HTTP Model)

- Adam to propose something/work on this, and analyse and describe
  differences between his and Florent's existing work. (wrt common
  Java tools)

- Put the draft back on the website, with a "parked" warning. (wrt
  SQL)

- eXist expressed interest in providing feedback about how they
  extended the format to represent webapps.

- Florent to look at relationship between PAckaging System and XSLT
  3.0 packages.

- Update (merge) the wiki at W3C with the content from expath.org, to
  be sure no information is lost.

- Update the link on the expath.org menu bar, pointing to the wiki, to
  point to the W3C one.

- Shut down the wiki on expath.org and remove the related software
  from the server.

We started by setting the agenda, based on notes sent by the
community.


** Agenda

- Parameters/properties/maps/etc.
- XParse
- Schema access
- Finalization of File Module
- Process for making final
- Current state of Archive Module
- Determination of official EXPath modules
- HTTP Client Module V2 ? (and HTTP Model?)
- Common Java tools for extensions
- SQL
- Dynamic evaluation
- Status of the EXPath packaging system spec + usage [Romain]


** Parameters/properties/maps/etc.

John Lumley asked about a "standard model for options/params/props":
https://lists.w3.org/Archives/Public/public-expath/2015Feb/0003.html.

First, we agreed that a module must clearly state the XPath baseline
it is supposed to support (is it for XPath 1.0, 3.0, 3.1?)  If the
module is designed to be compatible with XPath 1.0, using maps for
instance is not an option at all.

Pursuing interoperability does not make it possible to use the
solution "allow both maps or XML elements, and an implementation can
decide to support either one or both".  That of course introduces
interoperability problems, as a user has never the insurance that her
code will work on 2 different processors.

The consensus is to let the editor decide what is best for a
particular module: sometimes using a map makes more sense, sometimes
it is using an XML element.  The way to use each one should be
consistent accross modules though.

Action items:

- Define a "standard" for each possibility ("if using XML, use a
  @name, or rather the name of the element", etc.)

- Creating a "good practice" or "design rules" or "editor notes"
  document or area on the website or on the wiki, to define such good
  practice as they are discuss in the course of action.

- Reply to John's email, describe what is above, and let him lead the
  particular discussion on options.


** XParse

The group was not sure of the opportunity of an extension module here.
It felt that alternatives exist, like a library in standard XQuery
(like using REx).

The group does not want to stop anyone to work on any module, but
thinks that going through the standardization process is probably too
much here...

Action items:

- Reply to John's email, explaining the above.


** Schema access

The group aknowledges that there is some interest in providing schema
components and information through functions.  Either based on the
schema components in scope, or to access (that is, introspect) schema
properties from a node ("has this node complex content?", etc.)

Action items:

- Create a page (on the wiki, or on the website?) for "modules of
  interest", for ideas, or asking for help, or to centralize info
  about modules no one wrote a draft for, but we have discussed at
  some point...  In order to capture what has been said about
  potential modules.


** Finalization of File Module

It's been noted that file:children is achievable by file:list, but
there is no objection to add it as a convenience function.

Agreed on all 3 new functions.

Christian said test suite is up to date.  The group agreed, on his
recommendation, that next version will be 1.0!

Action items:

- Add the "definition" for "current working directory" in 2.2, saying
  it's implementation-defined.


** Process for making final

The question has been raised about how is a draft promoted to 1.0.

The group restated the (purposely) loosely defined editorial process.
The editor is in charge here.  The editor must at very least ask the
community for comments on a version that he/she thinks is ready to be
final, and feel that there is a consensus to move it to final stage.

Common sense is the key here.

Test coverage must be good enough.

Action items:

- Document this in a FAQ, or in an editorial rules page (the chair
  notes that no one pronounced the exact words "process document").


** Current state of Archive Module

See below.


** Determination of official EXPath modules

First, the list of modules as they appear on both wikis (at expath.org
and at w3.org) is:

- Archive
- Binary
- Crypto
- File
- Geo
- HTTP Client
- Packaging
- SQL
- Webapp
- ZIP

The group considers "official" the following modules:

- Binary
- File [ready to be pushed to 1.0]
- HTTP Client [ready to be pushed to 1.0]
- Packaging [ready to be pushed to 1.0]
- Webapp [need to be pushed forward]
- Archive [need to be pushed forward]

The following modules have draft, but are "dormant":

- Crypto
- Geo [ask for status]
- SQL

The following module is retired:

- ZIP (superseeded by the Archive module)

The group is not sure about the status of the Archive module.  We need
to ask John, and see if we need to park it, or if he will push it
forward.

Mike and Hans-Juergen mentioned interest in working on the SQL module.
Claudius mentioned he wants to work again on the Crypto module and
push it towards 1.0.

Action items:

- Put a warning in the "dormant" draft, to tell they are parked for
  now, and looking for an editor.

- Ask Peter for status on Geo.

- Ask John for the status of Archive, and either park it (add a
  warning) or push it forward.

- Add a warning in the ZIP module (as being superseeded by the Archive
  module), depending on the answer of John wrt the status of Archive.


** HTTP Client v1

Need to be pushed to 1.0.

There is a need for a comprehensive test suite first.  The group
discussed the way to write tests for a HTTP Client.  (1) The first
approach is to write an actual server, e.g. as a Java Servlet, which
responds to some specific HTTP actions with a defined response
(returning specific codes, specific body, headers, etc.) (2) The
second approach is to use QT3 by extending the context to include HTTP
information (the same way, saying that a specific HTTP request must
return this or that, but in a declarative way).

Florent already has someting according to (1) and is ready to improve
it.  Adam prefers (2) and will see if and how it is possible to add it
to QT3.

It has been noted that for (1), not only the webapp has to be deployed
to a public place, it must also be deployable locally (e.g. using any
Tomcat or Jetty instance if it is a WAR file, so it can be integrated
in build processes without depending on an actual connection to the
wild wild web).

Action items:

- Write tests to have enough coverage.


** Packaging testing

Discussing testing of the HTTP Client, the group asked asked how to
write tests for the Packaging System.  QT3 cannot be used (at least
not alone).  Options are to (1) create a set of test packages, both
valid and non-valid, covering different cases, and (2) write a set of
queries/stylesheets/pipelines using components in those packages (once
again, some will be not valid to test for failures), etc.

Action items:

- Write tests for the Packaging System.


** HTTP Client Module V2 ? (and HTTP Model?)

The group did not have time to discuss this point.  Adam and Florent
expressed interest in working on a HTTP Model (containing an XML
structure definition, maybe expressed as a schema, and a set of
functions to access some parts of it).

The HTTP Client and Webapp modules would then be adapted to use this
common model, on both the client and server sides.  Such a model could
also be used as a common format to store HTTP requests, e.g. in logs
or in test suites.

Action items:

- Add this to the page "modules of interest", created for "Schema
  access".


** Common Java tools for extensions

The group expressed interest for common Java tools to write
extensions.  A common data model to use in extension functions, a
common API to declare extension functions.  That would enable one to
write extension functions in Java in a generic way (or at least enable
reusing as much as possible between several implementations).

There has been some independent work on this area by both Adam and
Florent, available at:

- https://github.com/exquery/exquery/tree/xdm-model/xdm
- https://github.com/exquery/exquery/blob/master/expath-file-module/src/main/scala/org/exquery/expath/module/file/FileModule.scala#L54
- https://github.com/adamretter/exist-expath-file-module/blob/master/src/main/scala/org/exist/expath/module/file/FileModule.scala
- https://github.com/fgeorges/expath-file-java
- https://github.com/fgeorges/expath-file-saxon

Action items:

- Adam to propose something/work on this, and analyse and describe
  differences between his and Florent's existing work.


** SQL

Editor welcome!  Both Hans-Juergen and Saxonica expressed some
interest here.

Action items:

- Put the draft back on the website, with a "parked" warning.


** Dynamic evaluation

The group noted that some developments in XPath, XSLT and XQuery 3.0
and 3.1 solve some use cases that are typically the use cases for
dynamic evaluation.  Function items where mentioned for instance.

An editor is anyway welcome to work on this.  No use case where
provided.  So it is not clear whether this is about XQuery or XPath
dynamic evaluation.  The XPath dynamic evalutation in XSLT 3.0 might
be a good start to back port it as an XPath function itself.  If
someone still wants to work on this.


** Status of the EXPath packaging system spec + usage [Romain]

The status of the Packaging System spec is stable (the editor feels it
is ready to be pushed to 1.0).  It is widely used in eXist.  It is the
base for the Webapp module as well, which is used on several public
websites.  CXAN is also providing support to distribute packages.

Mike asked about relationship with XSLT 3.0 packages.

Action items:

- eXist expressed interest in providing feedback about how they
  extended the format to represent webapps.

- Florent to look at relationship between Packaging System and XSLT
  3.0 packages.


** Infrastructure

The group noted that there are 2 wikis, one at http://wiki.expath.org/
and one at https://www.w3.org/community/expath/wiki/.  Florent is
happy to shut down the one at expath.org.

Action items:

- Update (merge) the wiki at W3C with the content from expath.org, to
  be sure no information is lost.

- Update the link on the expath.org menu bar, pointing to the wiki, to
  point to the W3C one.

- Shut down the wiki on expath.org and remove the related software
  from the server.

Comments welcome.  Thank you all for attending and sending comments
before the meeting!

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Received on Saturday, 14 February 2015 12:19:59 UTC