[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] "null" to "empty string"
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. -- Benoit mailto:benoit@itedo.com 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]