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

[Lofton Henderson <lofton@rockynet.com>]

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.