W3C

XML Processing Model WG

Meeting 109, 24 Apr 2008

Agenda

See also: IRC log

Attendees

Present
Norm, Vojtech, Paul, Richard, Alex, Andrew, Michael_[xx:13]
Regrets
Alessandro, Rui
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/04/24-agenda

Norm: I'd like to add this morning's email threads

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/04/17-minutes

Accepted.

Next meeting: telcon 1 May 2008?

Vojtech gives regrets.

Consideration of the proposed next working draft.

-> http://www.w3.org/XML/XProc/docs/langspec.html

No questions or comments.

Henry will provide updated DTDs and W3C XML Schemas before 1 May.

Default context for options and variables

Norm attempts to summarize

Norm: We could allow a sequence, but on balance I'd rather not.

-> http://www.w3.org/mid/546c6c1c0804230152q5b9eccc0ta1737307cc143e32@mail.gmail.com

Norm: If we leave it an error now, we can always make it not an error later.
... Does anyone want to argue for a change?

None heard, the status quo prevails.

p:declare-step/p:import in p:declare-step (for atomic steps)

Norm summarizes.

-> http://www.w3.org/mid/m24p9rv5jq.fsf@nwalsh.com

Henry: Sounds right to me

Proposed: Make the changes Norm suggests.

Accepted.

Exclude prefixes on p:inline

-> http://www.w3.org/mid/f5bmynjnz1v.fsf@hildegard.inf.ed.ac.uk

Henry: It's a shameless lift from XSLT 2.0, very lightly edited.
... If we haven't changed our minds about doing this, the only thing that really requires peoples attention is the inventory of namespaces
... whcih are excluded by definition. I chose to exclude the two that might actually appear at the top-level in a pipeline.
... I excldued the error namespace and the instance prefix, because I don't think those are going to occur.

Norm: I don't think the .../xproc/1.0 "namespace" is every going to be bound.

<MSM> What if my pipeline is creating a pipeline?

Norm is confused about stripping the namespace.

Henry: If you want to use the namespace, you can add it back in another step.
... Eliminates any namespace on every node on the tree.

Alex: But it gets put *back in* by namespace fixup.

Henry: Yeah, I guess that works.

Norm: Bah. Do we really need to do this?

Alex: I think it's a very good idea. There are lots of situations where if you want to inline something, having a namespace declaration could be bad for the end result. There are environments where extra namespaces mean different things. IE freaks out on HTML with namespace declarations, for example.
... It may be an edge case, but it's a crucial edge case.

<MSM> [I don't understand Henry's argument that you MUST remove it everywhere. Why not just say the child of p:inline doesn't inherit any of the specified bindings, so that if it rebinds them they will be there.

Henry: When you need it, you really need it.

Alex: And I think it's easy to describe.
... Getting p:inline right is real work.

Michael: Why do you have to remove them everywhere?

Henry: There's no gaurantee that the datamodel that you have is efficiently implemented. So removing an in-scope namespace from my parent doesn't remove it from me.

Michael: You have to recompute them, but I think it's a mistake to confuse information with APIs.

Henry: It appears to only remove it in one place, but that's because if you have a literal XML fragment in your XSLT stylesheet, the removal applies to all of them.

Some discussion of the XSLT case.

Richard: The XSLT case is copying nodes from the stylesheet to the result. So they aren't copied.

Henry: Right, so it's the same for us. Up until this point, there was no necessity to copy and now there is.

Some discussion of whether nodes that are 'eq' to each other can get passed to different steps.

Richard: I wonder if there's a whole can of worms unaddressed here.

Henry: I think anyone who uses any kind of stateful data model doesn't have a problem here.

Richard: Suppose you ahve a sequence and the thing you do is count the union of the nodes in the sequence.

Henry: We need to have this in the test suite.

Richard: The excluding of namespaces seems to amount to a "when necessary".

Norm: Anyone against doing this?

None heard.

Michael: I think being able to trim namespace declarations is extremely useful. This seems unnecessarily complicated.
... I agree that XSLT 2.0 does exactly the same thing. Maybe Alex is right that namespace fixup saves it for those of us who use one of the excluded namespaces.
... Do we have the same sort of namespace fixup rules?

Norm: Yes.

Richard: The case where namespace prefix doesn't work is when the prefix is used in content. Because then it isn't noticed.
... Namespace fixup won't gaurantee that you get the right prefix.

Norm: True.

Vojtech: I think the prefixes are the author's responsibility.

Richard: But the excluded namespaces will remove the bindings.

Vojtech: If the XProc namespace is removed automatically, that's a problem. But if you remove the prefix, that's your problem.

Richard: That's not the way it works in XSLT. You specify it with a prefix, but it suppresses the namespace nodes that that prefix maps to.

Henry: So, worst case, you need to use a namespace-rename step.

Proposed: We adopt Henry's proposal for the 1 May draft.

Accepted.

What happens when @xpath-versions are mixed.

Norm: Attempts to summarize from http://www.w3.org/mid/546c6c1c0804232256p71ee6e0dke3008132c75ff58a@mail.gmail.com
... We allow @name, @psvi-required and @xpath-version on the decl. of atomic steps.
... I think they're mostly harmless on atomic steps andw es houldn't worry abou tit.
... What do we want to say about mixed @xpath-versions across calls?
... I think the obvious answers are either, ignore the nested ones or its an error.

Consider:

<p:pipeline xpath-version="2.0">

<p:declare-step type="ex:foo" xpath-version="1.0"/>

<ex:foo/>

</p:pipeline>

Vojtech: The default is 1.0 so what happens with the base steps.

Norm: That's a good point.
... I don't think we can expect implementations to do both.

Henry: The problem is in libraries.

Norm: I think we need to say that an unspecified version is license to use whatever you want and mixing them is a dynamic error.

Henry: How do we avoid screwing users unnecessarily. And simultaneiously avoid giving them weird results.

Norm: Uhm...

Henry: What we want is late binding.

Vojtech: If the implementation is prepared to switch, then it should work.

Norm muses

Vojtech: I think the default now is 1.0.

Norm: Static analysis should always show what versions could be used, so maybe late binding is possible.

<scribe> ACTION: Norm to propose how @xpath-version should deal with mixed versions. [recorded in http://www.w3.org/2008/04/24-xproc-minutes.html#action01]

Any other business?

None heard.

Adjourned.

Summary of Action Items

[NEW] ACTION: Norm to propose how @xpath-version should deal with mixed versions. [recorded in http://www.w3.org/2008/04/24-xproc-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/05/01 16:11:26 $