- From: <Nick_Van_den_Bleeken@inventivedesigners.com>
- Date: Wed, 5 Apr 2006 16:49:03 +0200
- To: "Allan Beaufour" <beaufour@gmail.com>
- Cc: www-forms@w3.org
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