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.

Let's look carefully at all *but* the Standard Library

We use those kind of types for attribute content

* NCName
* QName
* XSLT Match Pattern
* XPath expression
* Boolean
* Enumeration (e.g. {"document", "parameter"})
* NMTOKENS (e.g. prefix list }
* AnyURI
* Integer
* String

My first goal was to have the same typing annotation for option in
Standard Library

Reading through this, I came to thoses important points :

* We don't have an error (nor static nor dynamic) for the case when
the user provides and invalid XPath or XSLT match pattern especially
for options (because we can provide them trough @select). More
generally, we should provide an error for unexpected values (say
"vrai" for boolean, etc.)

* I eard objections saying that we don't have typing system for
document which is not so true. An infoset has already a two dimensions
typing : sequence(yes/no), kind(document/parameter)

* Whatever we want to do typing or not, implementers will have to
inforce this typing. The less we do that clearly, the more we are
prone to intereoperability problems : I even eard an important point
from Richard, about implementation inforcing a stricter subset of
XPath and rejecting the rest. They should not be conformant
implementation and that need to be clear.

* Last point, we reached now 35 steps in Standard Library, and we need
to have informations (say typing annotation or whatever) which should
help **author** (and also implementor) to have a quick sight on the
step signature (I repeat, as it is today the case for all but Standard
Library)

Mohamed


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Friday, 24 August 2007 06:24:33 UTC