Re[2]: [cgmo-webcgm] Problem: about empty/null node lists

[Benoit Bezaire <benoit@itedo.com>]

Hi Forrest,

Are you sure about your reply, I ask because I'm a bit surprise. See
inline for detail....

Tuesday, September 6, 2005, 4:41:49 PM, Forrest wrote:

FC> Lofton,

FC> In our implementation if a function returns a WebCGMString or a
FC> WebCGMNode, and there is nothing to return, we return NULL.
But we agreed that 'nothing to return' for WebCGMString would return
an empty string (i.e., "" in JS). See:
http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00036.html
There were no objections or alternate proposal sent to the mailing
list.

Returning NULL for a WebCGMNode is fine.

FC> If a function returns a WebCGMNodeList and there are no nodes, we
FC> return an empty string.
Do you mean empty string or empty list?

-- 
 Benoit   mailto:benoit@itedo.com

 
FC> Regards,
FC> Forrest



FC> -----Original Message-----
FC> From: Lofton Henderson [mailto:lofton@rockynet.com] 
FC> Sent: Friday, September 02, 2005 6:10 PM
FC> To: cgmo-webcgm@lists.oasis-open.org
FC> Subject: [cgmo-webcgm] Problem: about empty/null node lists

FC> Implementors, et al --

FC> Your prompt attention and feedback is needed...

FC> I had trouble interpreting and implementing some bits of the spec, while
FC> writing the Text Node test.  Specifically, with the 'hasChildNodes()' and
FC> 'childNodes' sub-test (see 5.7.4, WebCGMNode interface).

FC> The spec says:  "If there are no children, this returns an empty 
FC> WebCGMNodeList".  Nodes of type TEXT_NODE never have any children.

FC> So the problem I had -- what is an "empty WebCGMNodeList"?  If 
FC> hasChildNodes() is false, then which of the following is meant?

FC> 1.) myTextNode.childNodes.count==0 ?
FC> 2.) or, myTextNode.childNodes==null  ?

FC> It is a subtle difference -- if the meaning and the implementation is #2,
FC> then #1 results in JS throwing an "object error".

FC> I have talked some with Benoit about it.  Part of that dialog is below.  I
FC> would like to hear from other implementors (and Benoit, of course).  This
FC> may seem a small question, but as Ben says, its impact on implementations
FC> is not small.  We need to resolve it *quickly*.

FC> For reference, I scanned the spec for all things that can return a
FC> WebCGMNodeList.  Here is what the spec says:

FC> WebCGMNode.childnodes:  says "returns an empty WebCGMNodeList"
FC> WebCGMNode.attributes:  says "or null if the WebCGMNode doesn't have any
FC> attributes"
FC> WebCGMNode.getElementsByTagNameNS:  says nothing.
FC> WebCGMPicture.getAppStructureById: says "..returns empty WebCGMNodeList."
FC> WebCGMPicture.getAppStructuresByName:  says "...returns null."

FC> (Consistency would be nice!)

FC> Note that there are two similar/related questions:
FC> i.) empty/null WebCGMString.
FC> ii.) "null" WebCGMNode.
FC> As I recall, we decided these a while ago:
FC> i.) always empty string (JS:  myString.length==0,  myString=="" are both
FC> true)
FC> ii.) null (JS:  myObject==null)

FC> The spec text does *not* reflect these decisions (at least I can't find it)
FC> -- that will be fixed.  (E.g., namespaceURI, which is type WebCGMString,
FC> still talks about "null").  Let's stick with the WebCGMNodeList problem for
FC> this thread.

FC> Here are some of Benoit's comments about the empty/null WebCGMNodeList
FC> question, by reference to the list of 5 cases above:

FC> At 01:07 PM 9/2/2005 -0400, Benoit Bezaire wrote:
>>[...]
>>I've raised this kind of issue 3 months ago; and it's still
>>not fixed, see: 
>>http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00036.html
>>... the other
>>implementers ... [should] have commented on this a loooooong time ago
>>while writing test files or sending implementation feedback.
>>
>>LH> WebCGMNode.childnodes says "returns an empty WebCGMNodeList"
>>Here, from my perspective, saying "or null if the WebCGMNode doesn't
>>have any children" would simplify my life (but we would be diverging
>>from the XML DOM spec). Or maybe Forrest and Ulrich are returning NULL
>>as well, I have no idea.
>>
>>LH> WebCGMNode.attributes says "or null if the WebCGMNode doesn't have any
>>LH> attributes"
>>This is fine with me.
>>
>>LH> WebCGMNode.getElementsByTagNameNS says nothing.
>>LH> WebCGMPicture.getAppStructureById says "..returns empty
FC> WebCGMNodeList."
>>Here, our implementation returns null (like the XML DOM).
>>
>>LH> WebCGMPicture.getAppStructuresByName says "...returns null."
>>These three (getElementsByTagNameNS, getAppStructureById,
>>getAppStructuresByName), should, in my opinion, behave the same way.
>>Again, I have no idea what other implementers are doing.
>>
>>The reason I'm frustrated is that these changes even though they seem
>>simple are not simple (because of the Live Node concept, reference
>>counting etc...).
>>Any change to the wording means that the tests have to be revisited
>>and everyone has to regenerate an implementation matrix. (How long
>>have you been running after implementation matrices). We need to
>>resolve this ASAP (like early next week)! Note: Monday is a Canadian
>>public holiday.
>>
>>LH> So ... is 'null' (maps to JS 'null' keyword) synonymous with empty
>>LH> list, or not?
>>In my opinion, an empty list is not null, it's an object (a list) with
>>no references inside the list.

FC> This should be on the Wednesday Agenda, and we need some attention and
FC> feedback before then.

FC> Regards,
FC> -Lofton.