W3C

XML Processing Model WG

Meeting 45, 30 Nov 2006

Agenda

See also: IRC log

Attendees

Present
Norm, Rui, Paul, Richard, Mohamed, Murray, Andrew
Regrets
Henry, Michael, Alessandro, Alex
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/11/30-agenda.html

Accepted.

Accept minutes from the previous meetings?

-> http://www.w3.org/XML/XProc/2006/11/16-minutes.html

Accepted.

-> http://www.w3.org/XML/XProc/2006/11/09-minutes.html

Accepted.

Next meeting: telcon 7 Dec 2006?

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]

Review of open action items

A-13-01: continued (Michael isn't here)

Technical agenda

Review of 27 November draft

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

No comments.

Attribute names

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0065.html

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?

Murray: Yes.

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.
... 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.

Accepted.

<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.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0076.html

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 runtime.
... 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.

Accepted.

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.

Accepted.

<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]

Any other business?

Mohamed: I sent some small corrections and a new RNC grammar.

Norm: Thanks, I think those are editorial, I'll take care of them.

Adjourned.

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/12/12 15:44:48 $