- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 19 Jul 2007 12:08:58 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87ps2oidet.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/07/19-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 75, 19 Jul 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Paul, Norm, Rui, Alessandro, Alex, Andrew, Mohamed
Regrets
Richard, Henry
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 26 July 2007
4. Review of 17 July 2007 draft.
5. "Minimum" set of serialization options
6. p:map proposal.
7. p:make-uris-absolute proposal
8. p:add-xml-base-attributes proposal
9. Grouping in p:wrap-sequence
10. Making href optional on p:log proposal
11. Questions about defaulting and syntactic shortcuts
12. Questions about xsl:message from XSLT
13. Issues between here and Last Call:
14. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/07/19-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/07/12-minutes
Accepted.
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[9]]
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.
Accepted.
p:add-xml-base-attributes proposal
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jul/0155.html
Proposal: Required step V1.
Accepted.
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.
Accepted.
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.
Accepted
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.
Adjourned
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[16]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/07/19-agenda
[3] http://www.w3.org/2007/07/19-xproc-irc
[9] http://www.w3.org/2007/07/19-xproc-minutes.html#action01
[16] http://www.w3.org/2007/07/19-xproc-minutes.html#action01
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[17] version 1.128 (CVS
log[18])
$Date: 2007/07/19 16:08:03 $
Received on Thursday, 19 July 2007 16:10:32 UTC