Draft Review

Section 1, Introduction :

    * Second paragraph: The last parenthetical remark should just
      be made into a sentence.
    * Can't read the smallest text on Figure 2.

Section 2, Pipeline Concepts :
    * I'm not sure we want to use the term "subpipeline" for a
      contected set of steps.  Having subpipeline label this concept
      means we'll have a conflict for running pipelines as steps--which
      is truly a sub-pipeline.

Section 2.1, Components :
    * Last paragraph: In the definition of matching the component
      signature there is the state "it specifies inputs that are not
      declared".  In the case of the document aggregation component,
      all the inputs are not explicitly declared because there can
      be any number of inputs.  As such, this definition will needs
      some work in conjunction with component declarations.

Section 2.2:
    * there is no mention of the error output

Section 2.4: Component Graph
    * I don't think "Component Graph" is the right term here as
      Components don't describe their interconnections.  "Step graph"
      would be more correct given our current terminology but that
      sounds strange.  Maybe we could use the term "Flow Graph" ?
    * The definition of connected needs some work because we don't
      talk about paths and that's the standard definition from
      graph theory.  If we want to avoid graph theory, maybe:

      "Components A and B are connected if they are either
       directly or indirectly connected.  A component A is directly
       connected to B if an output of A is associated with an input
       port of B.  Component A is indirectly connected to B if there
       is a chain of directly connected components that allows
       traversal from A to B."

       While I could see the potential use of term "indirectly
       connected", I don't see that we need it right now.  I'm OK
       with it remaining--deleting it is easy later!

Section 3.3 Viewport

    The example needs to be better.  Maybe:

    "For example, a viewport might accept an XHTML document as its
     input and turn all MathML elements into renderings of the
     Mathematics in SVG."

Section 4.1.3 Syntactic Shortcuts

    * The use of the term "user-defined components" seems out-of-place
      here.  I don't think of 'choose' as user-defined.

    * Per our non-decision today, the use of 'declare-input' in the
      choose is now not valid.

    * The use of 'delcare-parameter' seems like it should be just a
      'parameter' element.

    * s/param/parameter/g

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.

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

Section 4.2.2:
    * Shouldn't declare-input allow an 'href' attribute?  I can see
      that being very useful where you know there is a static document
      in the environment and you'd like to specify the binding in the
      pipeline document rather than outside.

Section 4.2.3:
    * I think declare-output should support here documents.

Section 4.2.6:
    * s/param/parameter/g
    * input over which the select is running is missing.
    * I'd like to have a 'value' attribute for literal values.

Section 4.2.7
    * s/param/parameter/g
    * I think the attribute should be named 'names' since it is a list.

Section 4.2.8, 4.2.9 and 4.2.11
    * here we have 'declare-input' but 'choose' doesn't.
    * 'declare-parameter' (or 'parameter') is missing.

Section 4.2.10:
    * I think the 'choose', 'when', and 'otherwise' should all start
      with the same content model:

      (p:declare-input*,p:decalre-output*,p:declare-parameter, ...)

Section 4.2.13:
    * Can a component definition have both named input ports and
      a wild card?  This might be helpful for certain kind of
      aggregation or packaging components that take arbitrary
      inputs and organized them given a "template" on a named
      port.  This seems technically OK to me.

Section 4.2.14:
    * pipeline libraries should have an optional name for error
      reporting.


-- 
--Alex Milowski

Received on Thursday, 31 August 2006 22:14:45 UTC