Re: Where are things ignored

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| ht writes:
|
|> In the RelaxNG grammar as published, in fact _ignorable elements_ are
|> only allowed in subpipelines.  In the DTD as published, they are only
|> allowed in the prologue of p:pipeline and p:pipeline-library.  I guess
|> _neither_ of these is correct, but what _is_ correct?
|>
|> Despite the trickiness of defining this, I think it really should be
|> "as a child of container elements, or of p:pipeline-library, at _any_
|> position".  I'm going to rewrite the DTD and XSDL schema to implement
|> this.
|
| Sigh.  Implementing this makes me wonder again what's really right --
| if we do what I say above, since an extension element can function
| either appear in the prologue or in the subpipeline of containers,
| that sort of implies that it can function as a crypto-declaration or
| crypto-binding as well as a crypto-step.  If so, why not in the
| prologue of atomic steps?  What do we imagine extension elements are
| _for_ now that we have a documentation sandbox, anyway?  Do we have
| _any_ putative examples or use cases to help with this?

I imagine that they're for configuration information associated with
implementation-defined steps.

  <p:pipeline ...>
     <px:database-info>
       <px:user>nwalsh</px:user>
       <px:password>password</px:password>
     </px:database-info>

     <px:yml-serialization indent="yes"/>
     ...
  </p:pipeline>

As such, I think I'd be content to say that for V1 they should *only*
be allowed as the children of a p:pipeline. (I don't even think it's
necessary to allow them in a p:pipeline-library, though I won't fuss
if others do.)

I don't think we need to allow them in atomic steps and I think it
would be reasonable to limit their location to the 'subpipeline'
pattern.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything is temporary.
http://nwalsh.com/            |