[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] Problem: about empty/null node lists
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]