CARVIEW |
Select Language
HTTP/2 200
date: Fri, 10 Oct 2025 23:49:18 GMT
content-type: text/html
content-encoding: gzip
last-modified: Thu, 13 Jul 2023 17:44:51 GMT
cache-control: max-age=2592000, public
expires: Sun, 09 Nov 2025 23:49:18 GMT
vary: Accept-Encoding
access-control-allow-origin: *
x-request-id: 98ca036fdea9165e
strict-transport-security: max-age=15552015; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
cf-cache-status: EXPIRED
set-cookie: __cf_bm=gMuUIKWoqbCan51t.Jh27Dun_sPoJVeYFxFanbUbo.4-1760140158-1.0.1.1-QwjD20jTi.SCj7mzWuO7BWHgUQ.KhCQbwVCuBKdClXpiq6V7WcXzuPqybqIdjxHh.ZyOvsMCLYXiZP_ZtLZpoyfvEwCLVly1bucPrKEQeGI; path=/; expires=Sat, 11-Oct-25 00:19:18 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None
server: cloudflare
cf-ray: 98ca036fdea9165e-BLR
alt-svc: h3=":443"; ma=86400
Re: SimpleTypes derived by restriction from Ray Waldin on 2000-04-26 (www-xml-schema-comments@w3.org from April to June 2000)
Re: SimpleTypes derived by restriction
- From: Ray Waldin <rwaldin@pacbell.net>
- Date: Wed, 26 Apr 2000 03:51:53 -0700
- To: <www-xml-schema-comments@w3.org>
- Message-ID: <000301bfaf6d$6fb08a40$bec90640@lexica.net>
My apologies for the incorrect examples. Here's what I meant... <simpleType name="firstType" base="decimal"> <minInclusive value="1"/> <maxInclusive value="10"/> </simpleType> <simpleType name="secondType" base="firstType"> <minInclusive value="2"/> <maxInclusive value="5"/> </simpleType> <simpleType name="thirdType" base="firstType"> <minInclusive value="0"/> <maxInclusive value="11"/> </simpleType> -Ray > Hello, > > I have some questions and a comment concerning SimpleTypes derived "by > restriction". To illustrate: > > <simpleType name="firstType" base="decimal"> > <minInclusive value="1"/> > <maxInclusive value="10"/> > </simpleType> > > <simpleType name="secondType" base="firstType"> > <minInclusive="2"/> > <maxInclusive="5"/> > </simpleType> > > This seems perfectly acceptible as secondType is derived from firstType "by > restricting its value space", by specifying "more restrictive" values for > some facets. Here's a case that's not so obvious, using "less restrictive" > values: > > <simpleType name="thirdType" base="firstType"> > <minInclusive="0"/> > <maxInclusive="11"/> > </simpleType> > > My questions: > > Is this disallowed or just pointless? In other words, should a schema > processor regard this type derivation as an error, or simply produce a > thirdType which is no more restrictive than firstType? > > What does "more restrictive" mean for the period and duration facets? Can > period and duration be re-specified in any meaningful way or is > re-specifying either of these values disallowed? > > If a derived type re-specifies the pattern facet (as in the case of NCName > and Name), are schema processors expected to: > A) ensure that a derived type specifies a "more restrictive" pattern > than its base type, or > B) check all patterns in a type's derivation hierarchy when validating > an instance of that type? > > My comment: > > The datatypes spec should elaborate on the expected behavior of schema > processors when encountering derived types which re-specify values for each > facet. > > -Ray
Received on Wednesday, 26 April 2000 06:49:08 UTC