W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2002

Re: Hex Expression

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 11 Aug 2002 17:27:45 +0100
Message-ID: <155307410803.20020811172745@jenitennison.com>
To: xmlschema-dev@w3.org, "Michael Rossi" <mrossi@csc.com>

Hi Michael,

> BTW - I did notice that there's a hexBinary type already in the
> spec. My hesitation in using it was that it (obviously) implies a
> hex encoding of binary data. I'm simply dealing with Hex data
> (although it always comes down to binary at some point, of course
> :-). Are there any processing implications of using hexBinary to be
> concerned about? TIA.

As I understand it, an application will internally store the value of
an xs:hexBinary node as the bytes that the hex encoding signifies, so
obviously the storage requirements will be a lot less than it storing
the characters representing the hex encoding of that stream
(especially when you consider that the internal character encoding of
the application is likely to be UTF-16, using 2 bytes for each
character, so each actual byte ends up being represented internally in
4 bytes). If you're only using small sets of data, that probably
doesn't matter, though.

I'm not clear why you don't want to use xs:hexBinary as the data type
for your node. It would provide you with your regexp checking for
free, and it sounds as though it's more accurate to say that the value
*is* hex rather than that it *is* a sequence of characters.

The equivalent of:

<xs:simpleType name="8bytes">
  <xs:restriction base="xs:token">
    <xs:pattern value="[0-9a-fA-F]{16}" />


<xs:simpleType name="8bytes">
  <xs:restriction base="xs:hexBinary">
    <xs:length value="8" />

if you want to change it.



Jeni Tennison
Received on Sunday, 11 August 2002 12:27:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC