RE: [xri] Feedback on section 12 of WD11-ED06

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

Wil, thanks for this. I'm just finishing processing Gabe's feedback and
sending email to the list about the three issues it raised (one of which is
the forward slash issue in Path matching that you also raised).

I'll go over your feedback and process it into ED07 this afternoon and send
a response with the disposition of each item.

=Drummond 

> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Tuesday, October 23, 2007 12:50 PM
> To: XRI TC
> Subject: [xri] Feedback on section 12 of WD11-ED06
> 
> 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.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php