Allowing explict null Type and Path in XRD

["Drummond Reed" <drummond.reed@cordance.net>]

A question Wil Tan sent me last week made me stop and think hard about
allowing XRD authors to specify an empty Type or Path element as a way of
controlling default behaviour in an XRD.

The more I thought about it, the more I became convinced it was a good idea.
Look at the following service element examples:

(A)
<Service>
	<Type>xri://@example/(+some.service)*($v*1.0)<Type>
	<Type/>
	<URI>http://example.com/some/service</URI>
</Service>

(B)
<Service>
	<Type>xri://@example/(+some.service)*($v*1.0)<Type>
	<Path/>
	<URI>http://example.com/some/service</URI>
</Service>

Both of these make it very clear that these are the service endpoints that a
resolver should select if: a) no Type is explicitly declared, or b) no Path
is explicitly declared. (Note that Type has precedence, i.e., if any Service
has an empty Type element and no Type is declared in resolution, that
Service will be selected no matter what the Path is.)

If these empty elements were NOT present in the XRD, then the same behaviour
currently specified upon would prevail, i.e., no Type match would go to Path
selection and no Path match would go to Default Type selection.

This also has the advantage of faster resolution response times for XRIs
with empty Paths because if an empty Path element is declared, a client
application is not forced to make a second round trip to a $res*local or
$res*path service endpoint to get the URI for a null path.

So I recommend making this change in Working Draft 10 Editor's Draft 05
(which I am still working on.)

If anyone sees any issues with this approach that I'm missing, please post
to the list ASAP, otherwise I will incorporate this into Editor's Draft 05.

=Drummond