- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 22 Mar 2007 12:16:02 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87wt19s18d.fsf@nwalsh.com>
See: http://www.w3.org/XML/XProc/2007/03/22-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
22 Mar 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Murray, Alessandro, Andrew, Henry, Alex
Regrets
Mohamed
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 29 Mar 2007
4. Review of editor's draft
5. Placement of ignored content?
6. Import precedence
7. Pipeline visibility
8. Order of input/output/param/option
9. Interpretation of type name on declare-step
10. Review of the step library
11. Output from components that currently have no output.
12. Solution for the caching problem
13. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/03/22-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/03/15-minutes.html
Accepted.
Next meeting: telcon 29 Mar 2007
No regrets given.
Review of editor's draft
-> http://www.w3.org/XML/XProc/docs/langspec.html
Norm: Anyone think we can't publish this as a PWD?
Henry: I'm worried that some of the XML examples are wrong.
Norm: I'll fix the XML
... Any other showstoppers?
None heard
Norm: I went through the last week or so's mail and identified several
issues that we've been discussing.
Placement of ignored content?
Norm: Can you put documention inside of p:pipe or p:document or p:inline?
Murray: I think we should have an element dedicated to documentation
instead of playing games with ignored prefixes.
Norm: Having an element for documentation does not eliminate the need for
ignored preixes.
<Zakim> MSM, you wanted to agree with Murray
Michael: I wanted to agree with Murray. You don't want to get rid of
ignored content but you want to limit it to extensions.
... Documentation is a well understood need, so label it that.
Norm: Mohamed also agreed in IRC
Henry: I'm happy to leave the question of where documentation is allowed
to the editor, but I don't want it to be allowed in p:inline. The p:inline
content shouldn't have any special rules.
... If you don't want it to go through the pipeline, don't put it in
p:inline.
Norm: I'm hearing a proposal to have p:documentation element that is just
for documentation.
Murray: You might want to spell it with a shorter word.
Norm: Such as?
Murray: p:readme?
Norm: I don't like that one, how about p:doc?
<MSM> [p:doc works for me]
Norm: Everybody happy with p:doc?
Ok
Norm: Do we now want to rename "ignored-prefixes", "extension-prefixes"
Murray: What for?
Norm tries to explain.
Norm: I don't think we have to worry about where p:ignored-prefixes is
allowed or any defaults for ignored prefixes now that we have a
documentation element.
Import precedence
<ht> HST agrees, subject to my comment about p:inline. . .
Norm: The question is, should you be to declare a step or define a
pipeline with the same name as some declared step or pipeline that you
imported from a library.
Henry: It seems relatively cheap but relatively unlikely to be useful. But
it's probably better than ignoring the issue.
Murray: I'm worried about the security issue and spoofing of pipelines.
<ht> OK, so A imports and overlays part of B, and I import A and B, what
do I get?
Murray: If your library imports Alex's, but you've put some subtle change
in, maybe you can steal data from me. Or maybe I'll have a hard time
debugging it.
Henry: I'm convinced, let's not doit.
Norm: Me too.
Pipeline visibility
Norm: Can two pipelines defined in the same library see each other?
Murray: Yes, of course.
Norm: I think a consequence of this is that order no longer matters.
... So you can't do a single pass, you have to be prepared to encounter
qnames for pipelines that you haven't seen declarations for yet.
Order of input/output/param/option
Norm: Do we define the content of step with a sequence or a choice group?
Murray: What Jeni says makes sense
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0174.html
Murray: I think you have to have all the declarations first
Henry: I think it's pointless to allow variability of only limited
utility.
Murray: I want them to be in any order, as long as they come before the
first step.
... While I can somewhat appreciate Henry's position, I don't see that
there's any great cost.
Henry: I don't feel strongly.
Norm: Anyone strongly in favor of the status quo?
... Ok, let's change it for the next draft and add a note to the spec
soliciting feedback on this point.
Interpretation of type name on declare-step
Norm: Is an unprefixed name in the type attribute of p:declare-step
implicitly in the default namespace a la Schema rules, or in no namespace,
a la XSLT rules.
... Henry, you wanted the Schema rules, Alessandro, Alex, and Norm prefer
the XSLT rules.
... Anyone other than Henry arguing for the schema rules?
Murray: I'm confused.
Norm tries to explain.
Murray: If I now write a pipeline and I want to use that process and I
have a namespace bound to the prefix, example:
<Zakim> ht, you wanted to make the Dan Connolly point
Henry: If we adopt the proposal, then some names won't be in any namespace
and as Dan Connolly observes, all things should be have a URI.
... We're in an inconsistent position for libraries which is the full
equivalent of the schema position.
... I prefer the following summary of the schema rules: whenever something
is a reference, the full namespace bindings are available, but for naming
things you don't use the namespace bindings at all.
... That's what we did for pipelines and libraries, but not what we've
done for types, so I'm in an impossible position.
Norm: We don't need to answer this for the next draft, so I'm going to
move on.
Murray: Ok, though I'm tending to lean towards Norm's answer because I
think XSLT is going to be closer than Schema for our users.
Review of the step library
-> http://www.w3.org/XML/XProc/docs/langspec.html#std-components
Norm: I sent in some minor comments, Henry did to. Alex, did you get
anything off list?
Alex: No, not really.
Norm: Any components that anyone would prefer not to see in the next
working draft?
Henry: Yes, if we're not going to settle the caching question until after
this draft, then we should remove the xinclude-with-sequence component.
Alex: I'm happy to exclude it for now.
Henry: I support the sequence of schemas
... We looked at the minor components for most of a telcon (when I was
chairing pro-tem)
... I'm not sure we've ended up with all the things we talked about.
Output from components that currently have no output.
Norm: Murray suggested that the components that currently have no output
could usefully have a single output that identifies the location where the
content was actually written.
Henry: Yes, it does mean that components that succeed always have output.
Norm: Can you update the draft along those lines, Alex?
Alex: I wonder if we could use this to deal with non-XML results from
httpRequest?
... This and the httpRequest object have their own sort of component
vocabularies.
Norm: I'm happy if you put the result in a component results namespace or
something.
Proposal: The editors shall incorporate the decisions made today and the
resulting draft will be published as the next public working draft.
Accepted.
Alex: We didn't talk about the XSL-FO component, are we adding it?
Norm: Any objections?
None heard. Go for it.
Solution for the caching problem
Norm: I think there are three options: do nothing, you can't; do the
*-with-sequence thing; or do some form of caching.
Murray: I think we should do nothing. Too clever by half.
<MSM> [and in that case, give it the name Y-Include, also spelled "why
include?"]
Henry: In certain cases, because tools expect to reference things by URI,
and pipelines may want to compute those resources, that the ability to
assing URIs to things as they flow through the pipeline and then getting
access to those things by URI, in the case where that's what you want to
do, seems to be valuable.
... We could say "no, in V1". I'm opposed to doing it across the board
because it blows away streaming.
... You have to cache everything that comes out.
... That's much too high a burden. So my proposal was to adopt an
intermediate position, allowing authors to do caching for a part of the
pipeline.
Norm: I think we could decide not to do something for V1, but I'm really,
really reluctant to go there. I think it's horribly near a requirement.
Alex: I think caching is the right way to proceed but not for V1.
<ht> HST: I want to be able to set the base URI to "#banana", i.e., not
written out _anywhere_!
Murray: I assume that if I do a store, I should be able to refer to that
thing later.
Norm: That's caching.
Henry: The "later" doesn't have any real meaning in our specification.
Norm: We're out of time, we'll come back to this next week if we haven't
finished it in email.
Any other business?
None. Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/03/22-agenda.html
[3] http://www.w3.org/2007/03/22-xproc-irc
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[10] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[9] version 1.127 (CVS
log[10])
$Date: 2007/03/22 16:13:57 $
Received on Thursday, 22 March 2007 16:16:31 UTC