See also: IRC log
Norm gives regrets for 15 Jan, Henry to chair.
The first issue is 004, preserving base URI
Henry summarizes his mail. The net net is: "This means the spec. might be construed to have an interop problem, wrt processors which serialise between each step and those which don't."
Henry: We say in the spec that it isn't non-conforming to do fixup between each step.
Norm: I think we need to decide if we want to base the technical decision on avoiding the interop problem.
Henry: Why doesn't this problem
arise for namespace decls? Because we don't promise that
ignored prefixes actually remove namespace bindings. They come
back if they're needed.
... I don't know if that's relevant parallel or not.
Vojtech: What is the use case?
Norm: It's 5.11
Norm explains the rationale for the use case.
Some discussion. It turns out that performing steps 1, 4, 2, 3 would give the same result but would not require base URIs to be preserved after xml:base attributes are deleted.
Henry: Because we require base
URIs to be preserved, serialize-between-steps implementations
will have to add xml:base attributes.
... That means serialize everywhere processors will produce xml:base attributes where other processors won't.
Mohamed: You need to put it in
some namespace or something because xml:base won't work for all
the cases. Because we have to keep infoset and PSVI
information, you might need to have an XML document that
couldn't be used directly.
... You might have to serialize with some special intermediate form in order to preserve all the properties.
Norm: I suppose we could change the MUST on base URI to SHOULD.
Henry: That will definitely introduce interoperability problems.
Norm: I'm torn. I favor the interpretation that says removing xml:base doesn't change the base URI in the infoset, but I concede that that may be difficult for some implementations.
Vojtech: I just don't understand why removing the xml:base attribute doesn't change the underlying base URI property.
Mohamed: One other spec could give a sort-of answer, and that's XQuery update.
Norm: We need an answer...
Henry: I'd like to think about it a little longer, and I'd also like to have Richard involved.
Norm: Ok, I guess we can put it off until 8 Jan.
Vojtech: If we combine Norm's approach with Mohamed's suggestion, then it's doable even for processors that serialize between steps.
Henry: Yes, I think I'm leaning that way too, but I'd like to think about it some more.
Norm: Ok, we'll come back to this on 8 Jan.
Vojtech: We have other steps that can modify attributes, we should clarify their semantics as well.
... There's add-attribute, set-attributes, and string-replace
Norm: I think we can close this one.
Vojtech: There's a static error for except-prefixes on p:namespaces, I think there should say the same for exclude-inline-prefixes
Norm: Can we use the same error?
Vojtech: I think so, but we'll have to say something about #default and #all
Norm: How about we leave it to the editor, with instructions to use the same one if it's practical.
Henry: Fine with me.
Vojtech: I also raised a related
issue in 027.
... Should the unused namespace appear or not?
Henry: I think the reality is
that serializers differ on this point, and there's no right
... Both answers are right.
Norm: Do we agree that both are equally correct?
Mohamed: I don't agree. I think most processors do output the namespace even if it's unused.
Henry: You're right. I think I was wrong. There might be a QName in content that does need that prefix.
Vojtech: In the context of a pipeline, there are often extra prefixes.
Norm: I think Mohamed is right, the namespace binding is in scope and should appear on the result.
Proposed: The serializer must retain all in-scope namespaces whether they are used in XML element or attribute names or not.
Let's look at 003.
Norm explains the issue.
Norm: I think we have resolution on this, but we never discussed it in the WG.
Proposal: You do have to make the declarations visible in every pipeline.
Let's look at 002
Vojtech: You must always specify
an empty binding for a parameter input port if you don't have
... And even if you specify a number of p:with-param's then you still have to provide the binding.
... This all seems very inconvenient.
Vojtech: If you specify p:with-param, you still get the default binding which could be confusing.
Norm draws attention to the parallel with p:with-option and use of p:empty to make the binding explicitly empty.
Mohamed: I think parameters are
complicated, but we've made careful choices. I think the
decisions we've made put the burden on the implementor, which
is where they should be.
... Authors will make mistakes, but they'll learn this one quickly. Turning this around might make things even more difficult for the author who won't detect the errors until much later.
Norm: I think if we're going to
change this, we'd need a detailed change proposal for the spec
that covered all the cases.
... We might also have to go back to last call if we made these changes.
Vojtech: I can live with the status quo, but it's obviously confusing as the xproc-dev list shows.
Mohamed: I think we need to make it clear that writing a pipeline with parameters requires some care.
Norm: Does anyone want to persue making a change in this area?
Proposal: Leave the status quo.
Vojtech: We could also have a general error for "document is not a valid XProc instance"
Norm: Vojtech makes a good point about the number of possible errors that we might need.
Some discussion of 16, 38, and 44.
Norm: I agree that 16 is no
longer necessary, it's covered by 38.
... I propose that we close 001 by removing error 16 in favor of 38 and leaving the more general quesiton until we have more evidence about it.
Vojtech: I'm fine.
Mohamed: For next time, could we begin to discuss the processing model?
Norm: Yep. We need to start doing
... We should at least start talking about a requirements document for that.
Happy Holidays and Joyeux Noel!