RE: hasFeature continued

Joe Kesselman wrote:
> Given those, it still seems to me that this isn't a 
> hasFeature issue. 

Based on the flimsy research that I've done and by
gross speculation about what is going on behind the scenes,
I think this might be more pervasive than just hasFeature,
but also impacting the createElementNS and other *NS methods
and properties and impacts use from JScript, Visual Basic and
Visual Basic Script.

The results someone posted from the Mac version of IE
definitely seems at odds with the behavior that I have observed
on the Win version of IE.  There is definitely a chance that
this could turn out to be a phantom and would be nice to have
someone from Microsoft or Netscape sanity check our observations.

Shouldn't impact createDocument however since that null
is an object parameter.

> The binding must decide what "null" means for string arguments. 
> If they aren't
> allowed to accept the language's basic null, that's fine; the 
> binding must
> define a suitable replacement. That could be a magic reserved 
> string value,
> if all else fails -- preferably with a mnemonic assigned to 
> it so nobody
> codes dependencies on that specific string. (Simplest kluge, if you're
> working in Unicode, might to use a string containing a 
> character normally
> forbidden in XML.) 

That's the simplest kludge?  An empty string seems a lot simpler.  
Though an empty string is a legal URI, would treating it as equivalent
to a null namespace cause any serious harm?

> But it should be solved once, at the level where we map
> from IDL into that language's conventions, and be consistant 
> across the
> whole API.

Received on Friday, 13 July 2001 12:39:36 UTC