[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] "null" to "empty string"
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. I understand that. But the spec needs to be clarified, so that people don't have to go read ECMAScript in order to write WDOM scripts, or write 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). Yes, that has occurred to me also. Please propose an alternative. What should the spec say about these WebCGMString items: What should chapter 5 say? And what should the Appendix F (ECMAScript binding) say? [As I recall, the ECMAscript binding was going to say something about it: no-return-value WebCGMStrings map to ..., and no-return-value WebCGMNodes map to ..., and -- but there is 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. An alternative proposal would expedite discussion. -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]