OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: WD11 Issue #13 - Treatment of Empty and Null


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]