Subject: [Geopriv] Civic data types and whitespace

From: "Martin Thomson" <[email-masked]>
Date: Thu, 11 Aug 2005 10:39:02 +1000

I am working on developing a schema that includes the new civic types
defined in the DHCP Civic draft.  This has lead me to discover that the
original civilAddress definition uses the type xs:string for all of the
fields, which has some rather interesting side-effects.

The effect is that the following CANNOT be considered equivalent by a
processor:

    <civilAddress><A1>NSW</A1></civilAddress>
!=
    <civilAddress><A1> NSW </A1></civilAddress>

Even though these are clearly the same.  People don't expect this to happen,
so the xs:token type is defined, which is the type that people are used to
from HTML.

Therefore I propose that the xs:token type is employed in the new version so
that this equivalency problem is avoided.  Keeping in mind that these
whitespace characters can be added using character references if necessary
(&#20;, etc...)

Martin 
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Wed, 10 Aug 2005 21:31:26 -0400

On Aug 10, 2005, at 8:39 PM, Martin Thomson wrote:

> I am working on developing a schema that includes the new civic  
> types defined in the DHCP Civic draft.  This has lead me to  
> discover that the original civilAddress definition uses the type  
> xs:string for all of the fields, which has some rather interesting  
> side-effects.
>
> The effect is that the following CANNOT be considered equivalent by  
> a processor:
>
> Even though these are clearly the same.  People don't expect this  
> to happen, so the xs:token type is defined, which is the type that  
> people are used to from HTML.
>
> Therefore I propose that the xs:token type is employed in the new  
> version so that this equivalency problem is avoided.  Keeping in  
> mind that these whitespace characters can be added using character  
> references if necessary (&#20;, etc...)

Martin,

What obvious thing am I missing?

string is less restrictive than token, isn't it?

http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#token

Or is it that you want more restriction?
In that case, I think that token may not be what you are after either.

http://www.w3.org/TR/xmlschema-0/#CreatDt

-andy