[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] "null" to "empty string"
At 09:34 AM 9/7/2005 -0400, Benoit Bezaire wrote: >I'm not sure what the solution is. Our spec is not worse than the XML >DOM spec; and people are able to work with it. > >I may or may not come up with a proposal, depends if I find the time >for it. How about this: Use "empty string". Everywhere that it occurs, link it to a (new) discussion in "Basic data types", that says what "empty string" means in the binding-independent context. (Then in Appendix F, say what it means in ECMAScript.) Similarly for "null" (for WebCGMNode). Similarly for .... WebCGMNodeList. -Lofton. >Wednesday, September 7, 2005, 9:24:28 AM, Lofton wrote: > >LH> At 08:39 AM 9/7/2005 -0400, Benoit Bezaire wrote: > >>Tuesday, September 6, 2005, 8:36:43 PM, Lofton wrote: > >> > >>LH> At 07:42 PM 9/6/2005 -0400, Benoit Bezaire wrote: > >> >>[...] > >> >>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. > >> > >>LH> As I mentioned earlier, this resolution was not completely > >>LH> implemented in the CD2 text. > >>Yes, and I'm more or less saying that it irrelevant if the spec says > >>return null or empty string (for WebCGMString). As I explained in the > >>link above; the ECMAScript binding forces an implementation to return > >>empty string ("[...] String and null, cannot be compared (see page > >>55/56) because they are of different types). You are not compliant if > >>you do other wise. > >LH> I understand that. But the spec needs to be clarified, so that people >LH> don't have to go read ECMAScript in order to write WDOM scripts, or write >LH> implementations. > > > >>LH> Here is the proposed fix (in detail). > >> > >>LH> Following are the places where the null / empty-string distinction > might > >>LH> apply. I have indicated any needed changes: > >> > >>LH> (WebCGMNode.)nodeValue: in the table above change the 4 occurrences of > >>LH> "null" to "empty string". > >>LH> (WebCGMNode.)namespaceURI: change "null" to "empty string" > >>LH> (WebCGMNode.)prefix: change "null" to "empty string" > >>LH> (WebCGMNode.)localName: change "null" to "empty string" > >>LH> (WebCGMNode.)getAttributeNS return value: okay (already says "empty > >>string") > >>LH> (WebCGMPicture.)getAppStructureAttr return value: okay (already says > >>LH> "empty string") > >>LH> (WebCGMAttr.)name: s/is different from null/is different from empty > >>string/ > >>LH> (WebCGMAttr.)value: says nothing, but refers to > getAppStructureAttr (so > >>LH> does that suffice?) > >> > >>LH> All okay so far? > >>Not really. If you start using "empty string" in the specification, > >>you are tieing the spec to the ECMAScript binding, thus, possibly > >>preventing other bindings to be developed (i.e., a python binding may > >>in fact use NULL instead of empty string -just an example-). That's > >>why I believe the XML DOM often uses NULL/null as a return value > >>(regardless of the return type). > >LH> Yes, that has occurred to me also. > >LH> Please propose an alternative. What should the spec say about these >LH> WebCGMString items: What should chapter 5 say? And what should the >LH> Appendix F (ECMAScript binding) say? [As I recall, the ECMAscript binding >LH> was going to say something about it: no-return-value WebCGMStrings map to >LH> ..., and no-return-value WebCGMNodes map to ..., and -- but there is >LH> nothing there that I can find.] > > > >>LH> These are all attributes or method return values of type WebCGMString, > >>LH> where the question might reasonably arise. For some others, like > >>LH> WebCGMPicture.pictid, nothing is said, but it corresponds to the CGM > >>BegPic > >>LH> identifier parameter. I figure if that was "" in the metafile, then > >>it was > >>LH> unambiguous that the implementation would return "". Reasonable? Or > >>LH> should we say something? > >> > >>LH> If no objections, I will implement these changes in the text. > >>I think we need more discussion on this. > >LH> An alternative proposal would expedite discussion. > >LH> -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]