See also: IRC log
Date: 30 Nov 2006
<scribe> Meeting: 45
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<MoZ> Zakim has big troubles
Ok, we'll hope to hear from you soon
MoZ, you know there's a French local number for Zakim, right?
Who's going to XML 2006?
Just Norm apparently.
Norm sends regrets for 7 Dec 2006
Norm: I'll see about getting an alternate chair
<scribe> ACTION: Norm to find a chair for 7 Dec, tentatively proposes Henry [recorded in http://www.w3.org/2006/11/30-xproc-minutes.html#action01]
A-13-01: continued (Michael isn't here)
Review of 27 November draft
Richard: I was reminded that the
attribute names don't convey (to me) as much information as
they might about their purpose.
... In some cases, they don't seem to fit well with the elements they're on.
... For example, the port attribute is really giving a name, so name would be a better name.
... The "source" attribute might be better called "port".
... Input has port, step and source
... I'm proposing: name, source-step and source-port
Norm: I'm not really thrilled about the "source-" part.
Richard: I think it emphasizes
the purpose of the attribute.
... Explicitness is helpful, even if it would be nice if they were shorter.
Murray: I'm with Norm.
Paul: I'm sort of with Richard, but it isn't that important to me.
Mohamed: I think Richard's proposal is clearer.
Richard: I think that the "source" attribute is particularly bad because two attributes actually identify the source.
Murray: I have long thought that
the "source" should be a subordinate element.
... We're putting way to many attributes on these elements.
Norm: And for a literal input document, you'd have a wrapper?
Richard: Having wrapper elements does have the advantage that you can do a sequence of documents by having a sequence of wrapper elements.
Mohamed: I think the wrapper is a good idea, but maybe not in V1.
Richard: Since I'm not especially enthusiastic about the names I thought up, we could just make the decision in principle and try to come up with better names later.
Murray: I'll observe that by
taking the prefix off the attribute name and putting it in a
subordinate element means you only have to spell it once.
... If I say "source-port" and "source-step", then I have to spell out "source-" twice.
<MoZ> <source port='...' step='...' />
Murray: If I instead have a source element, then I only have to spell out "source-" once.
Richard: On the other hand, if we
did that, I don't think "source" would be a good name for
... It's supposed to distinguish between sources and hrefs.
Proposed: We want to change the names of the attributes on p:input and p:output to something like "name", "source-port" and "source-step". We'll have a week to discuss the actual names in email and we'll pick the winners next week.
<scribe> ACTION: Murray will write a proposal for using subordinate elements instead of attributes. [recorded in http://www.w3.org/2006/11/30-xproc-minutes.html#action02]
Norm: Next, in the same general topic, we have the "href" attribute.
Richard: I think "href" implies a
hypertext link and that's not what is going on in the case of
p:input. It's just a URI for the program to fetch at
... The relationship it's supposed to express is not between the program source document and the URI, ti's between the port crated inthe running program in the URI. Href implies a relationship between a source document and another document, it's a link. And this isn't a link.
Murray: what about XInclude?
Richard: Yes, but the
relationship in XInclude is a link.
... The same thing is sort-of true in include and import.
Murray: That's one way to look at it. Putting in the href is an alternate to a here document, so it's just like XInclude.
Richard: I see that, but that would only be true if you could go get it at compile time.
Murray: The context for href is the element that it appears on.
Richard: I would point out that
HTML only uses it for things that are like links, it uses "src"
on images, for examples.
... It's use as a general purpose pointer to URIs has arisen as a generalization over time.
Norm: The generalization that you alluded to has, in fact, occurred. Lots of people use href for pointer to URI.
Richard: I meant
*over*generalization, I meant it as a criticism.
... I'd like to call it source-uri, instead of href.
Murray: That ship has already sailed.
Norm: I think one user model is that there are careful distinctions between what URIs are for and another model is that they're URIs so always use "href".
Murray: I think my subordinate element proposal is really going to be attractive.
Straw poll: Do you support changing the name of the "href" attribute to something more explicitly related to it's use.
Results: 4 in favor, 3 opposed.
Paul: Names are hard. I don't know how to solve that. It seems a shame that we spend so much time on names.
Murray: I like where we are now, we're going to look at the specific issues that have been raised.
Richard: I think we did a fairly
good job on some of the names in the last week or so:
rearranging attributes on viewport and for-each.
... The ones on input/output/parameter are the bulk of the ones we need to consider again.
Proposal: We postpone decisions
on href until next week, after discussion of Murray's proposal
and see if it all just goes away.
... At the very least, this gives a week to think about it since Richard's mail only came out a few hours ago.
Are step name QNames or NCNames
Norm describes why he thinks maybe NCNames are simpler.
Murray: If you take the view that anything on the other name of the URI is fair game as a namespace document, you might imagine there being a pipeline who's step names are names in a namespace.
Richard: If that were the case, then the right way to do it would be to have a target namespace on a pipeline that would make all it's step names be in that namespace. And then if you were referring across them, you'd be using QNames. But there'd be no reason to give QNames to the steps in the pipeline.
Norm: In the XSLT case, the template names can be QNames, but almost no one ever does.
Richard: We could make them NCNames now and extend them to be QNames in the future.
Norm: For the names of steps.
Richard: We aren't talking about the types of components?
Norm: No, they have to be QNames.
Murray: I like Richard's proposal: NCNames now and we can make them QNames in the future if we need to.
Proposal: NCNames for now.
<scribe> ACTION: Norm to update the draft to use NCNames for the names of steps. [recorded in http://www.w3.org/2006/11/30-xproc-minutes.html#action03]
Mohamed: I sent some small corrections and a new RNC grammar.
Norm: Thanks, I think those are editorial, I'll take care of them.
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/elements on/attributes on/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Norm Rui Paul Richard Mohamed Murray Andrew Regrets: Henry Michael Alessandro Alex Agenda: http://www.w3.org/XML/XProc/2006/11/30-agenda.html Found Date: 30 Nov 2006 Guessing minutes URL: http://www.w3.org/2006/11/30-xproc-minutes.html People with action items: murray norm[End of scribe.perl diagnostic output]