Re: Typing of options and parameters

On 8/23/07, Norman Walsh <ndw@nwalsh.com> wrote:
> I'm getting a little ahead of Henry here, but a few thoughts.
>
> If we want to go beyond having these type attributes be purely
> advisory, then we have to provide some mechanism for defining what the
> types are. In my mind, that's an additional complexity that the
> specification doesn't need. (Even if it was purely advisory, I'd be
> concerned about the additional complexity, just in terms of explaining
> the advisory nature to users.)
>
> The obvious thing to use to describe the types are QNames. XML Schema
> Part 2 gives us a pretty widely interoperable set of simple types.
> Unfortunately, that set is incomplete if we want to handle the "XPath
> expression" vs. "XSLT match pattern" types, which was the motivational
> use case.
>
> That means we have to invent (at least) two new QNames, define them,
> and explain them. That, I feel pretty strongly, is too much complexity
> for the value.
>
> Even if it wasn't, the question would arise, how should we define
> them? I'm personally unmoved by an appeal to the XML Schema spec for
> this purpose.
>
> All in all, I think we should just give it a miss.

I think we're missing an important dynamic error in our library that we
need to address in that all steps should be able to report a dynamic error
if the option value is somehow incorrect.  Each step then needs to define
what "correct" values are for each option.

One possible middle ground solution would be that we could define
the option values as conforming to a XML Schema simple type without providing
a way to declare it.   In some ways, we already say that values are booleans,
enumerations of tokens,  or QNames and so stating an explicit XML Schema
simple type isn't that much of a stretch.

We could then say in the text of the step descriptions section (in one
place) that it
is a dynamic error if the option value does not conform to a required
constraints and list constraints in the descriptions of steps.

For example, the "match" options all have the constraints:

   * must be an XSLT match pattern
   * must conform to xsd:token

In the case where you must match an element, there would be additional
constraints:

   * must match an element

An implementor would only be required to support the types we have in our step
library (which should be a small subset).  If we stick to the built-in
XML Schema
simple types, that should be a very small set.

In this way we have:

   * one dynamic error for all violations of option constraints.
   * a mapping in the description to simple types as appropriate
   * a way for implementor to optionally use simple types to check
these values internally.

After writing all this, I have to admit that I'm even more motivated
to have a type
attribute and just have xpath options use xsd:token.  In the end,
we're going to need
a default dynamic error that our step library can use when an option value isn't
correct.  As such, it would be better for interoperability that we
describe the "lexical space"
of the option value and a XML Schema simple type does that  sufficiently.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 23 August 2007 20:23:02 UTC