Re: Pipeline Composition and our Recent Pipeline Name/Library Decision

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| I'd still prefer to keep pipeline/@name the same as [step]/@name,
| i.e. an NCName, and use an optional 'namespace' attribute to 'put' a
| pipeline in a namespace.  Likewise, I'd prefer to keep the 'namespace'
| attribute on pipeline-library.

I have a feeling neither of us is going to convince the other. It
doesn't feel like we're putting new information on the table, we
simply have different preferences.

I think users are going to draw the analogy between XProc steps and
XSLT templates whether we encourage them to do so or not. I don't know
of a single person who has ever been confused by the fact that
template names and mode names are QNames despite the fact that the
99.999% case is that they're NCNames. (I'm not claiming it's never
happened, I just don't know of anyone.)

I think the fact that with the current design you can't put a pipeline
in a namespace unless you put it in a library is an ugly wart.
Although I expect users to develop libraries of pipelines, I have a
feeling that it will be marginally easier for users to run pipelines
directly (rather than from a library) so there will be a motivation to
have collections of independent pipelines.

If you have one named "format" that does a really good job of
formatting specifications and Alex has one named "format" that does
MathML, I won't be able to import them both into my pipeline that
needs to format specifications with MathML in them. Granted, you might
not have chosen to put them in a namespace so I could be screwed
either way, but it seems more likely that I'll be able to talk you and
Alex into ht:format and am:format than I will of putting them in a
library.

I also think users are going to find the extra level of indirection,
that of putting the namespace attribute on the pipeline-library as a
way of putting pipelines in a namespace, confusing. When we say we did
it so that step names wouldn't have to be QNames, and that we didn't
want them to be QNames because that was somehow more complicated than
making them NCNames, I think they're going to be...amused.

But we need to be at Recommendation in less than 33 weeks so I'm not
going to reopen the issue if you and I and Alex are the only ones who
care.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.