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.