RE: hasFeature continued

> I wasn't trying to use ECMAScript-compatible terminology
>so much as avoiding anything other than IDL terminology, and let the
>ECMAScript mapping take care of the rest, which seems to me the proper
>level of isolation between the two.

That's my own concern. I'm not picky about how ECMASript chooses to bind
this, but I want the IDL-level description kept language-independent.


How is the ECMAScript binding dealing with the statement in Level 2 Core
1.1.8 that
     "Applications must use the value null as the namespaceURI
     parameter for methods if they wish to have no namespace."
Or the doctype parameter to createDocument, ("The type of document to be
created or null.")? Or any of the other cases where null is a legitimate
alternative to a string?

Given those, it still seems to me that this isn't a hasFeature issue. 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.) 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.

______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 13 July 2001 09:07:22 UTC