XML Processing Model WG

Meeting 76, 19 Jul 2007


See also: IRC log


Paul, Norm, Rui, Alessandro, Alex, Andrew, Mohamed
Richard, Henry


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/07/19-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/07/12-minutes


Next meeting: telcon 26 July 2007

Norm, Rui (for three weeks) give regrets, Paul to chair

Review of 17 July 2007 draft.

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

No comments

"Minimum" set of serialization options

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0166.html

Alex: There's not a lot of flexibility in the serialization spec.
... The spec is very clear about what you can/can't do in each method
... I plan to create a section to outline the serialization options.
... I'll also clarify the semantics of the options

Norm: We still have some flexibility; we can specify default values and not require any other values to be supported.

Alex: Even if we enumerate the defaults; the problem is that if we have these options users may use them

Norm: I'm suggesting that we just don't require that all the options be supported.

<MSM> [Sanity check - Norm is talking about a floor, not a ceiling, right?]

Uh. Yeah.

Norm gives up; will wait for concrete text to comment on

Michael: I'd paraphrase by saying that we don't need to require anything that serialization doesn't require us to require. I think it would be useful to have a list of the things that host languages are required to require. I think that's App D of the Serialization spec.
... We don't need to require implementations to support some of those if they're tedious.

Alex: Appendix D is a checklist of impl. defined features. I thought Norm was more concerned about the minimum bar for features.

Michael: The set of features is partitioned into things that impl. are required to support, ones that a language could support, and features which the serialization spec leaves implementation-dependent.

<alexmilowski> "The values NFC and none MUST be supported by the serializer."

<MSM> Section 10 says of host languages: "Specifications that set conformance criteria for their use of Serialization MUST NOT change the semantic definitions of Serialization as given in this specification, except by subsetting and/or compatible extensions. It is the responsibility of the host language to specify how serialization errors should be handled."

p:map proposal.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0010.html

Mohamed: It has had a lot of names, map, catalog, etc. The need was identified a long time ago, especially for xinclude-with-sequence. The proposal was to make a tool which can help defining a mapping between documents available and URIs.
... Maybe it's a bit too much for V1. Maybe we need to get more experience. A lighter version might be useful for defining mappings for XInclude.
... For V1 in XSLT 1.0, we don't have access to the document created by result-document extensions.
... It seems like there are a lot of use cases where there would be value in being able to provide hints to the pipeline.
... The other point was, even if we don't care about p:map or something, are we going to say something about how consistent resolution of names is within a pipeline.
... I think we need to open this box and try to draft something.

Norm: I thought years ago that we were going define a "pool" from which steps would get their URIs.
... It became clear that we wouldn't get consensus on that.

Alex: I'm sympathetic, I just don't think we can do that in V1.
... I can solve this by orchastrating a couple of pipelines.
... We'll learn if we really need a language construct for this.

Norm: I think there's risk of pain to users, but a lot of benefit in waiting for V2

Mohamed: So what's the proposed answer? Just implementation-defined.

Norm: Yes, implementation-defined, with maybe a note about the value of the ability to get access to URIs.

Some discussion of how this interacts with the proposed base-uri and make-absolute steps.

Mohamed: I'm still unsure, but maybe we should just move on.

Alex: It gives people the flexibility to use proxies, caches, etc.

Mohamed: I just want to be sure that every place we have URI, we can use a condition to know which implementation we're running.

<MSM> [it's important to give people some flexibility - but it's also important to give users of the term "conforming processor" a useful term defining a useful class of processor -- the utility of the phrase "conforming processor" is really the only thing any spec has to sell]

Norm: I don't hear consensus to add a step or language feature in V1.

Mohamed: I agree. I just want the spec to be clear about resolution.

<Zakim> MSM, you wanted to ask about extension

Michael: Does the the flexibility that we're talking about extend to allowing extension mechanisms to provide the functions Mohamed is talking about?

Norm: Yes. The constraints on extension are fairly limited.

<scribe> ACTION: Norm to clarify resolution of URIs in the spec [recorded in http://www.w3.org/2007/07/19-xproc-minutes.html#action01]

Mohamed: I just want to be sure, I felt that XProc was trying to resolve this part of XSLT problem, to make it possible to embed it and orchestrate it better.

Norm: I think we've improved things, we can chain arbitrary steps together; we just haven't tried to come between URI resolution and the bits you get back. I'm not sure we *can* go there.

p:make-uris-absolute proposal

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0156.html

Norm: It's hard to do this any other way; I'm in favor.

Alex: I'm in favor too
... Required or optional?

Norm: I'm inclined to make steps required unless they're an enormous burden to implement.

Proposal: Required step V1.


p:add-xml-base-attributes proposal

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0155.html

Proposal: Required step V1.


Grouping in p:wrap-sequence

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0152.html

Norm attempts to ask his question

Norm: I think all we need to do is make the output a sequence and clarify the adjacent stuff.


Making href optional on p:log proposal

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0149.html

Alessandro: My understanding is that p:log is intended for debugging; in general, when I look at other similar constructs, you don't have to specify where the data is going to go.
... Usually where the data goes is configured externally. I'd like to be able to do that in XProc.

Norm: Yeah, I can see that.

Mohamed: Since we say that there's only at most one p:log for each port, I think it makes sense.


Questions about defaulting and syntactic shortcuts

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0153.html

Norm: I don't really want to do these things, but like I said in the message, I don't have grounds to turn them down.

Alex: I'd like AVTs.

Norm: One of my input shortcuts clearly doesn't work, I don't think we should do any of them.

Alex: I don't think so either.

No changes.

Questions about xsl:message from XSLT

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0139.html

Norm: I think XSLT messages are a secondary output that you only get a hold of if there's an error.

Alex: I think you're right.

No changes.

Issues between here and Last Call:

Norm: I think base URI handling is handled by the steps we added today.

Alex: If a document comes out of a step, what's its base URI/

Norm: I think each step needs to say how it produces the base URIs of the documents it produces.

Mohamed: Do we need a p:base-uri() function?

Norm: I don't know.
... Does anyone else know of something that stands between here and Last Call.

Alex: Do we have to review our use cases and make sure we've hit them?

Norm: Have to, I don't know, should we, yes?

Mohamed: I'll give it a try.

Any other business?

So for the agenda next week, I think it'll consist of reviewing the draft that Alex and I produce and, if no one raises any issues, voting to take it to Last Call.


Summary of Action Items

[NEW] ACTION: Norm to clarify resolution of URIs in the spec [recorded in http://www.w3.org/2007/07/19-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/08/01 16:02:27 $