Re: Import precedence/Overriding pipelines

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Mmphh.  I suppose the use case you have in mind is where you have a
| library you mostly like, but there's something in it you need/want to
| change.

Yes.

| This seems much more plausible for pipelines than for step
| definitions, but it's probably easier to adopt a uniform approach.
|
| So I have _some_ sympathy with defining a story about precedence,
| following the SGML/XML external/internal subset story.

That's what I was thinking too, but I've sort of changed my mind.

For declared-steps, ones who's definition is implementation-defined,
how could changing the signature ever succeed?

What if one of the pipelines in the library uses the declared-step?
What does that mean? Does it use the local definition or the redeclared
definition?

The same is true of pipelines within the library. If one (can and does)
make a call to another, which definition does it get?

I think it might be simpler in V1 to just say, all attempts at
redefinition are an error.

If we are going to allow redefinition, for the use case where you really
like a library but you want to change one pipeline or component, I think
I could live with a rule that says:

1. The signatures must be identical
2. The redefined step/pipeline completely masks the other definition.
   In other words, the space of declared steps/pipelines is completely
   flat.

                                        Be seeing you,
                                          norm

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