See also: IRC log
Norm: I'd like to add this morning's email threads
Vojtech gives regrets.
No questions or comments.
Henry will provide updated DTDs and W3C XML Schemas before 1 May.
Norm attempts to summarize
Norm: We could allow a sequence, but on balance I'd rather not.
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.
Henry: Sounds right to me
Proposed: Make the changes Norm suggests.
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
... 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?
Michael: I think being able to
trim namespace declarations is extremely useful. This seems
... 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?
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.
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.
Norm: Attempts to summarize from
... 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.
<p:declare-step type="ex:foo" xpath-version="1.0"/>
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.
Henry: What we want is late binding.
Vojtech: If the implementation is prepared to switch, then it should work.
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]