Technical agenda

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.

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.