Copy of

                            XML Processing Model WG

Meeting 76 or 77, 26 Jul 2007

(The minutes of Jul 19 say that is the 75th, but the
agenda for this telcon says this will be the 77th???)



           Paul, Richard, Mohamed, Andrew, Alex, MSM (xx:12)

           Henry, Norm



>  1. Administrivia
>       1. Roll call.
>             * Regrets from Norm, Henry; Paul to chair.

See above.

>       2. Accept this agenda[4].


>       3. Accept the minutes[5] of 19 July 2007.


>       4. Next meeting: 2 Aug 2007.

No regrets given.

>  2. Technical
>       1. Add the p:directory step?

This was proposed on the public comment list.

Mohamed said that Norm and Jeni want to store a full URI.

There remain questions about the filter.

Richard and Alex think this should be an optional component.

Mohamed says there are some use cases that need this component.

ACTION to Alex:  Send email with your thoughts (and perhaps
an updated proposal) on the p:directory step.

>       2. Move optional steps to a WG Note or 
           other separate publication?

Proposed by Jeni so that we don't have to republish the
spec for optional components.  Norm doesn't mind.

Richard agrees in principle, but doesn't want to split
them off until later in the process, e.g., during CR.

Alex isn't comfortable putting the optional components
into a separate spec because most of them are important
things like XSL-FO.

Michael proposed that we leave the optional components
in the spec but say that other optional components may
be defined elsewhere.

CONSENSUS to leave the optional components in for at least
Last Call.  We can revisit this question at CR time.

>       3. Proposal to modify p:insert

Jeni:  whether to insert before or after the identified element.

Mohamed said we need four possible positions: before, inside
at the beginning, inside at the end, after.

Jeni proposed:
| I think all four options would be useful. I'd have position be
| "first-child", "last-child", "after" and "before". I'm not sure 
| there's an obvious default, which makes me think that it should
| be a required option.

That worked for Norm.

We had CONSENSUS on the telcon to go with the above proposal.

>       4. Proposal to default step and port

Proposed by Jeni at:
There was no email discussion of this to date.

Mohamed thinks we discussed this last year, and we had a good
reason not to pursue this, but he couldn't remember the details,
but he prefers not to do this now.

Richard:  we've gone through shorthand syntax since then, so
last year's discussions might not be relevant.  He's not sure
how useful this default would be, though he has no objection
in principle.  As long as it is consistent with the default
readable port defaulting, Richard would be in favor.

Alex hadn't seen the proposal before.  He doesn't object as
long as there is no technical problem, but he hasn't thought
hard about it yet.

CONSENSUS We are generally in favor as long as it doesn't 
break anything.

ACTION to Alex:  Think about the Proposal to default step 
and port and let us know if there are any technical difficulties.

>       5. Proposal to add a version attribute to p:pipeline 
           [our guess is the reference to p:pipe? was a typo]

Alex says we should also have it on p:pipeline-library
and make it required.  (At first) Mohamed agrees. 

Richard prefers it be optional.

Alex says that it should only be required on the
document element (either p:pipeline or p:pipeline-library).

Then Mohamed says he doesn't think we need version on
p:pipeline-library, but instead it should just be on
the p:pipeline's within the p:pipeline-library.

Alex says we need to know what version of declare-step
within a pipeline-library, so we do need the version
on pipeline-library.

Richard says we can resolve the issues of a mixed 
version library in V2.

We leaned toward adding a version attribute to 
p:pipeline and p:pipeline-library and make it required
(and maybe only allow it?) when the 
p:pipeline|p:pipeline-library element is the document

ACTION to Norm:  Consider the above discussion about
when to have a version attribute and see if he can
develop some specific wording.

>       6. Change XProc namespaces?
>             * To etc.?

Right now, we have a month in the namespace name, so 
the suggestion is to just use the year.

Mohamed prefers to use the
form and use the version attribute to know which version.

The latest process about namespaces is discussed at

Michael wonders if we aren't picking a nice namespace
name too soon, since we will probably be changing
things throughout the Last Call and CR periods.

We agree we want to be able to change up to Rec, and
we need to state that policy in our spec and namespace
name document.

ACTION to Norm:  Put a note in the spec and in the
namespace name document(s) saying that the namespace(s)
is(are) not stable until we get to Rec.

Given that there is such a note, we have CONSENSUS
to publish Last Call with .

Currently, we also have xproc-error and xproc-step
namespaces right now.  Alex wondered why we need

We didn't get to closure about whether we need all
three namespaces before the end of the call, but
for however many namespace names we have (and the
status quo is for 3), they would all be of the "ns" 
form with the proviso that we note in the spec and
in the namespace name documents that these namespaces
are in flux until Rec.

>  3. Any other business


> [4]
> [5]