W3C

- DRAFT -

XML Processing Model WG

Meeting 132, 18 Dec 2008

Agenda

See also: IRC log

Attendees

Present
Norm, Mohamed, Vojtech, Henry
Regrets
Andrew, Paul
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/12/18-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/12/11-minutes

Accepted.

Next meeting: telcon 8 Jan 2009?

Norm gives regrets for 15 Jan, Henry to chair.

Review CR comments

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/

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

-> http://www.w3.org/TR/2006/WD-xproc-requirements-20060411/#use-case-make-absolute-urls

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.

More discussion.

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.

Norm: Yes.
... There's add-attribute, set-attributes, and string-replace

006

Norm: I think we can close this one.

Yep

005

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 answer.
... 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.

<p:inline><doc>c:foo</doc></p:inline>

Proposed: The serializer must retain all in-scope namespaces whether they are used in XML element or attribute names or not.

Accepted.

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.

Accepted.

Let's look at 002

Vojtech: You must always specify an empty binding for a parameter input port if you don't have one.
... 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.

Norm

Norm: Yeah.

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?

None heard.

Proposal: Leave the status quo.

Accepted.

Issue 001

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: Agreed.

Accepted.

Any other business?

Mohamed: For next time, could we begin to discuss the processing model?

Norm: Yep. We need to start doing that.
... We should at least start talking about a requirements document for that.

Happy Holidays and Joyeux Noel!

Adjourned

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/07 15:23:56 $