ISSUE-45: Support for the use of xsi:type on schemaID element in header options document

There are pros and cons implicated by the suggested change.

Pros
- Values of types other than xsd:string can be used for
encoding schemaID.
- "12345" takes just 2 bytes in Unsigned Integer, but takes
6 bytes in String representation. (better compactness)

Cons:
- Incurs 1 bit penalty for xsi:nil attributes that occur
in schemaID elements, due to the addition of a production
for supporting xsi:type.
- Minimal implementations that only needed to implement String
and Unsigned Integer datatype representation would have to
implement many other datatype representations in case they
are used.
- There is a markup cost of 19 bits for denoting an xsi:type.
This is in addition to the value of the xsi:type attribute.
2 bits for AT(xsi:type)
3 bits for qname.uri (5 namespaces)
8 bits for qname.localname (string table hit)
6 bits for qname.localname (XSD compact-id - 46 names)
- How do you treat the schemaID integer value 12345 when you
expect texural "12345" to identify a schema? Any conversion
involved? Who decides whether to attempt to convert or not,
and what kind of conversion logic should be used?
DP says conversion need not be performed, which makes the
life a lot simpler.

The WG reached a consensus that adding the support for xsi:type on schemaID element might unnecessarily complicate the processing to the extent that it
seems to outweigh the benefit that would be resulted from doing so. (2009-10-07)