Re: Option types

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Today's discussion has raised the, for me at least, deep question of
| just what the types we have been semi-formally associating with step
| options really mean.  One way of framing this was suggested by Norm:
|
|   Are
|    <p:option name='attribute-name' value='x:foo'>...</p:option>
|   and
|    <p:option name='attribute-name' select="'x:foo'">...</p:option>
|
| indistinguishable, regardless of what, if anything, replaces the
| ellipses?

I think they should be.

| I guess I can live with this, but the spec. has to change to make
| clear that what is now described as the in-scope namespaces of the
| XPath dynamic context is available for _all_ option evaluation, and
| specify what namespace bindings are available for parameter
| evaluation.  Also, the fact that the prefixes in what we call QNames
| are interpreted relative to the in-scope namespaces as we define it
| needs to be made clear. I'm concerned about the impact of this on the
| spec. from the perspective of the 99%-case user, who only uses 'value'
| to set options and parameters, and wants to think of QName values as
| just-like-element-name QNames.

I don't think the 99% case will ever use p:namespaces, so I don't see
ordinary users ever having any trouble with it.

| OK, so having got that off my chest, where does this leave us with
| respect to a coherent proposal for adding type information to at least
| options?
|
| I propose that we add a 'type' attribute to p:option and p:parameter,
| and a 'type-prefixes' attribute to p:pipeline and p:pipeline-library,
| syntax and semantics as follows:
|
|  type-prefixes -- a whitespace-delimited list of prefixes, all of
|  which *must* have in-scope namespace declarations on the spot.
|
|  type -- A QName per XML Namespaces 1.1, which *must* have a prefix,
|  which *must* be in an ancestor's type-prefixes.  Interpreted to
|  produce a URI by concatenating the binding of the type prefix, a '#'
|  if it doesn't end with one already, and the local-name part.  This
|  URI identifies a type definition.  
|
|  Implementations *must* recognise and enforce the the types used in
|  section 7.1 below, namely xs:anyURI, xs:boolean, xs:integer, p:QName,
|  p:XPath-expression and p:XSLT-match-pattern, in their occurrences on

Adding our own type definitions just seems totally over-the-top to me.
And the fact that we'd have to to make a useful proposal is one of the
things that convinces me we shouldn't do this until V.next. If ever.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Whoever is abandoned by hope has also
http://nwalsh.com/            | been abandoned by fear; this is the
                              | meaning of the word "desperate."--
                              | Schopenhauer