Feedback on section 12 of WD11-ED06

["Tan, William" <William.Tan@neustar.biz>]

Here are my feedback on the service selection section of ED06. The line 
numbers are based on the word document after accepting all changes.


12.1 Line 2211 - "For each xrd:Service element in the final XRD, 
selection MUST follow the service endpoint selection logic defined in 
section 12.2".
This seems like we are prescribing a single for loop, even though the 
full process is described in 12.2. Perhaps something more like "Section 
12.2 describes the processing logic for selecting a set of SEPs from the 
final XRD based on the QXRI and other resolution input parameters"?


12.1 Line 2220 - s/241/221/


12.1 Line 2222 - I'm not sure if we should be defining Output Formats in 
section 7. The output formats seem very specific to the proxy resolver. 
IMHO the output of core resolution logic should be defined as an 
abstract data type, rather than concrete format.
 For example, OpenXRI returns a data structure, not a DOM document, for 
the resolveSEPToXRDS method.


12.2 Line 2226 - "Selection of service endpoints (SEPs) within an XRD is 
managed using service endpoint selection elements (SELs)."
Rather than introducing SELs here, we should talk about the general 
processing logic, something to the effect of "Selection of service 
endpoints (SEPs) within an XRD involves applying SEP matching rules 
(12.4) and SEL matching rules (12.3) to the set of all SEPs in the XRD, 
then applying SEP selection rules (12.5) to determine the output".


12.2 Line 2227 - "As defined in section 4.2.6, xrd:XRD/xrd:Service 
elements may contain three categories of selection elements: xrd:Type, 
xrd:Path, and xrd:MediaType."
When I first looked at section 12.2, I immediately zoomed in on the 
flowchart (ignoring the introductory paragraph) so I missed the sentence 
above. And when I got to section 12.3.1 line 2236 where it talks about 
"three categories of selection elements" I realized that I've not been 
introduced to the three categories. Some readers may be like me.
I suggest moving the sentence above into the introductory paragraph of 
section 12.3 because it is the logical place to introduce the three 
categories of SELs.


12.3.1 Table 21 - the precedence column begs some explanation, but I can 
only find mentions of it in 12.3.5. It seems that "precedence" is 
important for two reasons, of which 12.3.5 (multiple SELs matching rule) 
is one of them. The other reason is that Match Option is tri-state, so 
if an SEL is not a positive match, it doesn't automatically make it 
negative. I think there is a tendency for people to think -(+1) = -1


12.3.2 Table 22 - should we add two other states to the "value" column - 
/other/ and /absent/? This will complete all possible states of the 
match attribute (aside from empty string, which I will list separately 
below). It would be easy for the reader to have a glance at the table 
and know everything about how to process the match attribute.
If we do that, then the literal values should be quoted, i.e. "any", 
"default", "non-null" and "null", while /other /and /absent /are 
unquoted. We should specify the behavior for the resolver when it 
doesn't recognize the value (/other/).


12.3.3 Line 2253 - s/UNLESS the overriden/UNLESS overriden/


12.3.4 - why do we need this special rule? Isn't it backwards 
incompatible with WD10? This seems to conflict with the definition in 
section 12.3.2 that when the match attribute is absent, use the content. 
In this case the content is null, so it should just be equivalent to 
match="null".


12.3.5 - propose to move into 12.3.1.


12.3.6 - line 2269 and everywhere else - I propose that we don't allow 
the match attribute to be empty. It seems to be more a programming error 
to me if the match attribute is empty. By allowing this possibility, we 
are giving more ways to express the same meaning to XRD publishers and 
that might hurt interoperability and/or makes XRD harder to understand.


12.3.6 - line 2272 - "if an XRI, IRI, or URI does not include a local 
part, a trailing forward slash MUST be assumed" - that MUST NOT be 
assumed because for certain URI schemes, there simply isn't a local 
part. We should simply defer to the XRI and IRI syntax.


12.3.6 - line 2275 - s/comparisions/comparisons/


12.3.6 - line 2277 - "XRI resolvers MAY perform normalization of these 
values but MUST NOT be required to do so." This seems strange to me. XRI 
resolvers may normalize the value for comparison, but because XRI 
resolution (esp. w.r.t. Type element) is a much more controlled 
environment than the open web, we can probably just specify 
"Syntax-Based Normalization" in RFC3986. However, we are not saying that 
resolver normalize the value and place it back into the element, so we 
need to be clear that normalization is for comparison purposes only. And 
if we normalize, we should also normalize the


12.3.6 - Type element is in URI normal form, right? We should probably 
make it clear.


12.3.6 - line 2281 - "Any other result is a NEGATIVE match". Make it 
clear that this is an per-SEL match result (POSITIVE/DEFAULT/NEGATIVE), 
and not the per-category match option. I realize that we don't actually 
talk about the per-SEL match result and it could be confused with the 
per-category one specified in 12.3.1. It's only in the pseudocode that 
the distinction can be discerned.


12.3.7 - line 2287 - "If the value is a relative XRI or an IRI"
s/or an IRI/or IRI/
OR
s/or an IRI/or a relative IRI/


12.3.7 - line 2293 - s/, with the exception that it is not necessary to 
perform normalization after case folding.//
This probably originated from me, and I've tried to look for clues as to 
why we specified this way several times, and I looked _everywhere_ but 
couldn't find any reason. I know section 3.13 of Unicode did say 
"Normalization is not required before case folding, except for the 
character U+0345...", but that is _before_, and we don't save much by 
saving that step because implementations still have to normalize after 
case folding. In any case, I'm also thinking to change the MUST into a 
SHOULD, because it would be hard for scripting languages to comply, and 
I'm not sure if we want to call them non-conformant to the spec.

12.3.7 - line 2302 - "MUST be a NEGATIVE match", as above (line 2281)


12.3.7 - table 23
See my previous email in reply to Gabe regarding the stripping of 
leading slash from the Path value.
I have issues with a few examples, but would like to first discuss the 
above before delving into them.


12.6 - line 2369-2371: s/Matched/Seen/
I think the semantic of these flags is more accurately conveyed as 
"seen" rather than "matched".


12.6 - pseudocode - I think this is great - very readable and clear. 
Should you want to shorten it, though, I managed to save 13 lines by 
doing some optmization (which may sacrifice a bit of readability). Let 
me know if you're interested.


12.7.2 Table 25 - s/plus/including/g - "plus" may sound like a 
concatenation operator.


12.7.2 Table 25 - should we explicitly say that fragment should not be 
included for the "local" value?


12.7.6 line 2476 - should not allow append value to be empty.


12.7.6 line 2482 - s/QXRI component specified/QXRI component in URI 
Normal Form specified/


12.7.6 line 2487 - "If the value of the QXRI component specified in 
Table 25 is null ..."
Do we need this sentence? It's more explicit but seems redundant to me.


12.7.6 line 2497 - By applying URI construction during authority 
resolution, we are allowing components of the QXRI other than the 
authority to be used as inputs to authority resolution, which I'm 
nervous about.


I apologize if some of these had already been raised by Gabe or someone 
else.

=wil

p.s. I should read the spec and type out comments right away, rather 
than marking with pen and then transcribing, because the latter takes 
too long.