Typing of options and parameters

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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | One of the great misfortunes of mankind
http://nwalsh.com/            | is that even his good qualities are
                              | sometimes useless to him, and that the
                              | art of employing and well directing
                              | them is often the latest fruit of his
                              | experience.-- Chamfort