OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]