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 â‚¬