W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 1999

RE: Datatypes questions

From: Biron,Paul V <Paul.V.Biron@kp.org>
Date: Thu, 13 May 1999 11:42:50 -0700
Message-Id: <376E771642C1D2118DC300805FEAAF43B5B0@pars-exch-1.ca.kp.org>
To: "'Paul Prescod'" <paul@prescod.net>
Cc: www-xml-schema-comments@w3.org
> -----Original Message-----
> From:	Paul Prescod [SMTP:paul@prescod.net]
> Sent:	Wednesday, May 12, 1999 2:58 PM
> To:	Biron, Paul V; petsa@us.ibm.com; www-xml-schema-comments@w3.org
> Subject:	Datatypes questions
> 
> > "Issue (uri-scheme-facet): should we have a facet to allow a limitation 
> > to a specific scheme? It might be useful to able to say that something 
> > was not only a URI, but that it was a "mailto" and not a "http://...". 
> 
> No. I think it would be in bad form to restrict by protocol. If I invent
> httpplus next week my schema should not restrict me from using it. The
> much more interesting sort of restriction is by target -- i.e. "this link
> must go to an XML element with GI foo." But that might be out of scope.
> 
By "bad form" do you mean that individual type designers (and schema
authors) should steer clear of such things, and hence, we should not give
them the freedom to do so if they want to?

The inclusion of that issue was my idea.  The intention is to keep the basic
uri datatype, but to allow schema designers to create their own
user-generated subtypes which were restricted by scheme.  Including this
facet would not force anyone to use it, but would merely allow those who
wanted it to be able to use it.

The use case would be a schema author who wanted to do something like the
following in their own schema:

<datatype name="mailto">
	<basetype name="uri"/>
	<scheme>mailto</scheme>
</datatype>
<datatype name="phone">
	<basetype name="uri"/>
	<scheme>tel</scheme>
</datatype>
<!-- see http://www.w3.org/Addressing/schemes for a note on the tel: scheme
-->
<elementType name="contactInfo">
	<all>
		<elementType name="name">
			<datatypeRef name="string"/>
		</elementType>
		...
		<elementType name="phone">
			<datatypeRef name="phone"/>
		</elementType>
		<elementType name="email">
			<datatypeRef name="mailto"/>
		</elementType>
</elementType>

This would allow instances such as the following to be flagged as schema
invalid

<contactInfo>
	<name>Paul V. Biron</name>
	<phone>tel:+1-626-685-3529</phone>  <!-- valid tel: -->
	<email>http://www.kp.org</email>        <!-- invalid mailto: -->
</contactInfo>

> > Issue (picture-or-regex): Should the values of the 
> > [Lexical representation] facet be pictures, regexs, both or some 
> > other mechanism? 
> 
> Not only do we need both, I'm going to argue that we should be allowed to
> specify both for the same user-defined data type. Pictures are nice and
> simple. Regexps are powerful. One feature that pictures support that
> regexps do not is nice, guided editing. ###-####-#### can be easily
> rendered into a GUI. A regexp cannot. In the (admittedly rare) case that a
> type had both I would expect the picture to be used for guided editing and
> the regular expression for more complicated constraints. Of course the
> input would have to match both.
> 
Like Ashok, my initial reaction to allowing both a picture and a regex on
the same datatype is that doing so would be a bad idea.

The intention of having the picture constraints was that it might be simpler
for some users to write (and understand) simple constraints not to help UI
builders.  I'm hoping the next generation XHTML Forms work [1] will provide
the kind of UI pictures you want.

pvb
Received on Thursday, 13 May 1999 14:51:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:46 GMT