See also: IRC log
Norm, Rui (for three weeks) give regrets, Paul to chair
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?]
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."
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
... 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.
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.
Proposal: Required step V1.
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.
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.
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.
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.
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.
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.