Re: Draft Review

Norman Walsh wrote:
> | Section 3.3 Viewport
> |
> |    The example needs to be better.
> 
> What's wrong with it?

Just that encryption could cause people to assume some kind of
binary output and lead them off into the weeds.  Or assume we're
going to handle digital signatures "natively" (whatever that means).

> 
> | Section 4.2.1:
> |
> |    * The statement that the name must be unique make no sense when
> |      you aren't in the context of a pipeline library.  Maybe that
> |      should be moved to the pipeline library section.
> 
> I assume that a pipeline outside of a pipeline library cannot shadow
> the name of a pipeline within such a library, so I think it applies in
> both cases.

OK.  If that is the intent, then it just needs to be clarified what
"unique" means (e.g. unique within what set?).  That is, since pipelines
can be invoked as steps...

> |    * Maybe we should just replace all instances of 'declare-parameter'
> |      with 'parameter' since at the pipeline level it can work the same
> |      as in steps.  That is, where the parameter is calculated by a
> |      select on an input of the pipeline.  Then 'declare-parameter' is
> |      only in component declarations.
> 
> As long as we have the input/declare-input distinction, I think we should
> preserve the analagous param/declare-param distinction.

...but in all cases, you are declaring a parameter value.  I'm not sure
there is a distinction as in the input/declare-input case.

> | Section 4.2.7
> |    * s/param/parameter/g
> |    * I think the attribute should be named 'names' since it is a list.
> 
> It's not a list, it's a single QName, or *:NCName or NCName:*

Ah.  OK.  That wasn't clear.

> | Section 4.2.14:
> |    * pipeline libraries should have an optional name for error
> |      reporting.
> 
> Uhm, isn't it sufficient to identify the file?

Possibly... but the file location might not be as good as a name.

--Alex Milowski

Received on Monday, 11 September 2006 17:12:13 UTC