[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Absent Selection Elements (was WD11 Issue #13 - Treatment of Empty and Null)
|
Thanks, Wil, that’s one more down. See my
next message about timing of another call this week. =Drummond From: Tan, William
[mailto:William.Tan@neustar.biz] Indeed,
the new SEP flow is so much simpler that I’m happy with the optional
match=”default” elements. So,
yes please close the issue. From: Wil, We missed you on the TC call yesterday
(but your appointment with your wife takes precedence!) In reviewing the current status of XRI
Resolution 2.0 Working Draft 11 issues (http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11),
I have been checking the TC email list to make sure your recent questions have
been addressed. You asked the one below (over a month ago)
about absent selection elements (SELs) and match=”default”. Since then, as you
know, there has been a huge amount of discussion of SEP selection logic between
the editors assigned to this issue (unfortunately most of it offlist), which
has resulted in the proposal at http://wiki.oasis-open.org/xri/XriCd02/SepSelection.
On the basis of that proposal, do you
still hold the same opinion that you expressed below, i.e., that missing SELs
should be required, or are you fine with leaving this as it was in WD10, i.e., that
a missing SEL is equivalent to the SEL being present with an attribute of
match=”default”? I would strongly prefer the latter, as it
supports very simple SEPs, for example one that declares only a Type element
(which is how OpenID uses XRDS). In addition, I think it can be very simple
for a resolver to apply the bitflag logic we developed in the pseudocode at http://wiki.oasis-open.org/xri/XriCd02/SepSelection.
In fact, I reviewed it yesterday and realized that it did not actually address
the issue of missing SELs. So I added three more bitflags and modified the
first FOR loop and the DEFAULT SEP IF test so that if a SEL of any type is
absent in a SEP, that SEL match is automatically set to DEFAULT. Please look this over and see if you
agree. If so, let me know, and I will officially marked this issue as closed.
(See also the upcoming messages with other questions we have for you coming out
of yesterday’s TC call – we’re on a roll to close the rest of the WD11 issues
now!) Thanks, =Drummond From: In an
earlier mail to the list I proposed to eliminate the service selection step
that adds an element with match=”default” if the element was absent. I would
still like to explore that and would like to hear your opinions on it. By *not* adding missing elements, the service
selection has one less step. The overall effect of this change is:
This
also means that for issue #13:
This
would require changes to the currently deployed resolver implementations, but I
feel is a simplification that would not take too much work. However, existing
XRDs have to be re-provisioned with explicit elements with match=”default”. From: This email is for closure of issue #13 from the XRI
Resolution 2.0 Working Draft 11 Issues List wiki page at:
http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 Please review the following text and, if you don’t agree
with the proposed solution, please reply to the list. SILENCE WILL BE
INTERPRETED AS CLOSURE. ===
#13 - Section 8.2.1 – Clarifying Definition of Null and Empty (Wil Tan) === From
an email from Wil regarding section 8.2.1 point #2 of WD10 resolution spec: ''If
an xrd:Type, xrd:MediaType, or xrd:Path element is present but its contents are
empty, the value of the element MUST be considered null.'' What
is the significance of this statement? This
also brings up issues that I always had while reading the spec, i.e. what is
the definition of "null" in the document? For example, the table in
8.2.1 under the Matching Rule for "content": "the xrd:match
attribute is present but the attribute is omitted or its value is null."
To me, this looks like you mean either of: <Path>photos</Path> <Path
match=””>photos</Path> But
match=”” is not a valid enumerated value in the schema, so it should not even
be considered. It
seems to me that an empty string ("") and null should be considered
equivalent with respect to service selection. If that is the case, we probably
should specify it in the doc. DISCUSSION
ON 2006-8-17 TELECON Steve
proposed that: *
We do not distinguish between the empty value and null. *
If an attribute or element is not present, the value is considered null. *
If the attribute or element is present but the value is the empty string, it is
considered null. Marty
added that we should clarify that if an attribute or element is required, it is
not satisfied by being null by the above rules. Wil
pointed out that to avoid confusion we should also clarify that the value
"null" for the match attribute is an explicit value. We
should also be careful to distinguish between empty and null with regard to XML
elements vs. query parameters. CONCLUSION
#1 There
was concensus that for XRI resolution query parameters, we do NOT distinguish
between a parameter having an empty value and null (null being the absence of a
parameter). They are equivalent. REMAINING
OPEN ISSUE What
is still open is whether the same rule should apply to XML elements in an XRD,
i.e., should an element with an empty value (and no attributes) be equivalent
to the element being absent altogether? Wil
and Steve pointed out that this is not consistent with our rules for the match
attribute, which is assumed to have one value (match="default") if an
element is missing altogether, and another value (match="contents")
if the element is present. PROPOSED
SOLUTION Drummond
proposes to eliminate this inconsistency by specifying that if an XRD element
is present BUT: a) its value is empty, and b) it has no known XRD attributes, then
it is treated as equivalent to the element being absent, i.e., it's value is
considered to be null, and thus the value of the match attribute is assumed to
be match="default". This
would make it consistent that throughout all aspects of XRI resolution, the
presence of an element or parameter with an empty value is treated as
equivalent to the absence of that element or parameter, and from a programming
standpoint, both conditions are considered as equivalent to setting the value
of that element or parameter to null. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]