Re: Digging through section 6.2.1 / multiple types for an element

www-forms-request@w3.org wrote on 04/05/2006 03:57:53 PM:

> 
> On 4/5/06, Nick_Van_den_Bleeken@inventivedesigners.com
> <Nick_Van_den_Bleeken@inventivedesigners.com> wrote:
> > > So how bind type="" mixes with other types also belongs in schema
> > > land, which says:
> > > "1.2.1.2.4 If there is also a processor-stipulated type definition,
> > > the ·local type definition· must be validly derived from that type
> > > definition given its {prohibited substitutions}, as defined in Type
> > > Derivation OK (Complex) (§3.4.6) (if it is a complex type 
definition),
> > > or given the empty set, as defined in Type Derivation OK (Simple)
> > > (§3.14.6) (if it is a simple type definition)."
> > > [http://www.w3.org/TR/xmlschema-1/#cvc-elt]
> >
> > But if this is the case, then when you have an attribute of type 
string in
> > your schema you can't restrict it by using a type contsraint to an URI 
by
> > using anyURI?
> 
> Not as far as I can see, no. If it is xsd:string, any further
> refinements needs to derive from xsd:string.
> 
> But as I wrote, I'm no schema master.
>
I'm also no schema master ;), But it can be that it is the case if you 
read the schema spec, but is that what the original authors of the XForms 
spec meant, and more important is that how the users/implements think/want 
that it works. 
In my opinion it would be hard to sell that we have type constraints but 
we only allow derivations of the type that was specified in the schema. 

To go back to my example, if you now that the input needs to be an URI for 
this special case and the schema author decided to just put the string on 
it I have to create an derived type from string that has the same 
restrictions as URI. If I manage to do this, and the schema author decides 
to change the type to a type that he derived from string, then I need to 
adjust my form again ...
 
> --
> ... Allan
>

Nick



--------------------------------------------------
Inventive Designers' Email Disclaimer:

Received on Wednesday, 5 April 2006 14:49:00 UTC