Re[2]: [cgmo-webcgm] "null" to "empty string"

[Benoit Bezaire <benoit@itedo.com>]

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.