Minutes for XProc WG telcon of 2 Feb 2006

Attendees

   Present
           Rui, Alex, Paul, Murray, Vikas, Alessandro Erik, Andrew

   Regrets
           Richard, Henry, Norm, Jeni

   Chair
           Paul

   Scribe
           Paul

> 
>  1. Administrivia
>       1. Accept this agenda.

Accepted.

>       2. Accept minutes[3] from the previous teleconference

Accepted.

>       3. Next meeting: 16 Feb 2006.  Norm gives regrets.  MSM will
chair.

Regrets for 16 Feb:  Norm, Henry, Rui

>       4. Tech Plenary[4] registration is now open[5].
>             * The discounted rates at the conference hotel are only
>               available until 6 Feb 2006 (extended).

Expected:  Paul (but in the XSL-FO), Murray, Henry, Norm, Richard,
           Alex, Erik

>  2. Technical
>       1. XProc Requirements and Use Cases[6]

See below.

>  3. Any other business
> 
> [1] http://www.w3.org/XML/Processing/
> [3] http://www.w3.org/XML/XProc/2006/01/26-minutes.html
> [4] http://www.w3.org/2005/12/allgroupoverview.html
> [5] http://www.w3.org/2002/09/wbs/35195/TP2006/
> [6] http://www.w3.org/XML/XProc/docs/langreq.html
> 

Alex did a pass implementing our last week's decisions
in the 01 February 2006 version of 
http://www.w3.org/XML/XProc/docs/langreq.html

He still hasn't reorganized the requirements to be in the
same order as the design principles, but still plans to.

Vikas notes that we don't say anything the language being
declarative.  He prefers that the language be declarative.

ACTION to Vikas:  Start email on whether we want to say
that our language must be declarative including just what
it means to be declarative.

4.2 Streaming XML Pipelines
---------------------------
XML Pipelines should allow for the existence of streaming
pipelines in certain instances as an optional optimization.

We mean, we don't want to build into the model something
that prevents the ability to stream the pipeline processing,
but a given implementation need not support streaming.

ACTION to Alex:  Take a stab at defining streaming.

4.6 Minimal Component Support
-----------------------------
Is this list there complete?

Should RelaxNG be in the core set?

Alex explains that the idea of this requirement is for 
our spec to have a standard way to reference each of 
these components, but this isn't saying that any 
implementation is required to implement any one of 
these components.

But then the title of this requirement is misleading.

Murray is concerned about having steps that can be
ignored by an implementation (because the implementation
isn't required to support any particular component).

Erik explains a component wouldn't be ignored, but there
would either be a fallback or an error.

Erik questions whether there should be a requirement to
be able to run a pipeline in the case of errors.  Presumably,
instead one can just halt and catch fire.

[Paul isn't sure what requirement this refers to, and he
doesn't currently see such a requirement, but Alex's comments
made it sound like he thought there was already such a
requirement that we might delete later on.]

We agreed that the title is wrong.

ACTION to Alex:  Update the title of 4.6 to reflect that fact
that this requirement is about our spec providing a standard
way to reference common components (but not about requiring
support for any particular component).

It is still not clear whether we want our spec to mandate
support for any particular component.

ACTION to Alex:  Add a *proposed* requirement about mandating
support for some particular components (so we can debate it).

We ended the call at this requirement (4.6).

paul

Received on Thursday, 2 February 2006 17:06:46 UTC