Option types

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

Or, supposing I'm using W3C XML Schema 1.1, would I be wrong to write
a local element declaration for p:option inside p:add-attribute which
assigned itself the following type in case name=='attribute-name':

  <xs:complexType>
   . . .
   <xs:attribute name="value" type="xs:QName"/>
   . . .
  </xs:complexType>

?

I realised I had assumed the latter was OK, but our discussion today
forced me to conclude that a) I'm in the minority and b) for it to be
OK implies that the two alternatives at the beginning are _not_
equivalent (and that we might as well bar p:namespaces from inside
p:option[@value]).

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.

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
 the built-in step definitions from that section.  Implementations
 *may* recognise and enforce these or any other types in user- or
 implementation-specified step definitions.  It is
 implementation-determined how type URIs other than those used in
 section 7.1 are used to establish conditions for type-validity.

 For xs:anyURI, xs:boolean and xs:integer, the conditions for
 type-validity are as given in W3C XML Schema 1.0 Part 2, Datatypes.
 For p:QName, the conditions for type-validity are as given in W3C XML
 Schema 1.0 Part 2, Datatypes for xs:QName, with the in-scope
 namespaces being determined per 5.7.3, Option and Parameter
 Namespaces.  For p:XPath-expression and p:XSLT-match-pattern, . . .

 If an option declaration has a type, a processor *may* signal a
 dynamic error (xxx) if the conditions on type validity established by
 that type are not satisfied by a value specified or computed for a
 specific binding of that option.  Processors *must* signal errors
 with respect to option types specified in section 7.1.

 In a parameter binding has a type specified, a processor *may* signal
 a dynamic error (xxx) if the conditions on type validity established
 by that type are not satisfied by the value specified or computed by
 that binding.

 In an option declaration has type and a default value specified, a
 processor *may* signal a static error (xxx) if the conditions on type
 validity established by that type are not satisfied by the default
 value.


 
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFGzuL/kjnJixAXWBoRAtwCAJ4kG62opQdfUTeDMeAoo7csZOqvKwCcCeEZ
EK3BYrqgDArgFdAYIiSJCo8=
=qhLl
-----END PGP SIGNATURE-----

Received on Friday, 24 August 2007 13:54:16 UTC