RE: Objection to hexBinary and base64Binary

Charles:
The Schema WG discussed your comments on binary extensively in today's
call.
 
A number of us the the Schema WG would like to create abstract datatypes
that
define a value space.  Users could then associate these types with
lexical spaces
as they desired.  This would be the best solution to the problem you
raise but,
despite having spent quite a bit of effort on this, we have been unable
to come up 
with such a formulation.  We will keeping trying, though and perhaps
will have
something better in 1.1 or 2.0
 
On your comment re getting values out from DOM, the feeling was that DOM
should
store the value in the value space and you should be able to access it
in whatever 
form you wish.  Not being able to get the value out is a DOM issue, not
a Schema issue.
 
Michael Sp-McQ pointed out that you could create a union type of
hexBinary and base64Binary
and this may do what you want.  It was suggested that the type library
may want to offer
such a type.
 
Regards, Ashok  
	-----Original Message-----
	From: Charles Frankston [mailto:cbf@isovia.com] 
	Sent: Thursday, April 05, 2001 9:42 PM
	To: www-xml-schema-comments@w3.org
	Subject: Objection to hexBinary and base64Binary
	
	
	There was a change made to the binary datatype back in January,
between the Candidate Recommendation and the first Proposed
Recommendation:
	CR-53 Add built-in datatypes base64Binary and hexBinary Paul:
remove current binary type. Unfortunate consequence is that the two
types have no relation even though they have the same value space.
RESOLVED: that this change be made. 
	The original issue was raised in response to a request by James
Clark to pre-define base64binary and hexbinary as shortcuts for binary
with encoding facets of base64 and hex.  James didn't ask for the
bifurcation of the binary data type, and I think that result is far
worse than the simple convenience that James was asking for.  If the
standard goes to Recommendation with this in it, parsers will forever
have both these datatypes forever.
	 
	First let me state that I disagree with the James' original
request because it went in the wrong direction.  I always maintained the
most important principle for the lexical format of a datatype is that
there only be one for each datatype.  A large part of the purpose of
defining the datatypes is to aid interoperability.  The quickest and
easiest way to be interoperable is to standardize representations.  This
is why the WG correctly decided that the lexical format of datatypes
should not be internationalized.  The correct resolution to this
situation is to have only one binary encoding.
	 
	It is anticipated that future XML parsers will have support for
datatypes that will free applications from any knowledge of the
underlying lexical representation.  Treating the different lexical
representations of binary blobs as different datatypes will create a
ugly wart that will last forever.
	  
	There are two possible ways to fix this before going to
recommendation:
	 
	1.	return to the CR status of a binary datatype with an
encoding facet that could be either 'hex' or 'base64'. 
	2.	eliminate one of hexBinary or base64Binary, and call the
remaining type 'binary'.  *Note that this is the most conservative
decision*.  The missing encoding could always be added back, but once
released as an official recommendation parsers would be required to
support both encodings for all time.

Received on Friday, 13 April 2001 15:27:08 UTC