RE: Bugs in SysInfo WebIDL

Dom,

Thank you for doing the WebIDL check on this spec. Please see my response below.

> Running the WebIDL checker on the current editors draft of SysInfo and
> reviewing it manually, I've found the following problems:
> * SystemInfo.get() and SystemInfo.monitor() accepts either a name or a
> URI, but the spec doesn't explain the possible equivalence between them;
> based on section 5, I assume that invoking get with
> "http://www.w3.org/2009/dap/SysInfo/Power" should return the same
> results as invoking it with just "Power" but that should be stated
> explicitly; also, the comparison algorithm for the URIs should be
> clarified (I assume we want only a character-per-character comparison,
> without any normalization)

I will clarify this and note that it is char-per-char comparison.

> * "ErrorCB?" in the definition of SystemInfo.get and SystemInfo.monitor
> should be just "ErrorCB" (interface types are not nullable since they
> already allow the null value according to the WebIDL spec [1])

Will fix

> * the attribute info is defined on a number of *Attributes interfaces as
> of type "String?" instead of DOMString?

Will fix

> * although the syntax of arrays is not formally defined in WebIDL yet, I
> believe they are supposed to be written
> attribute DOMString[] foo;
> rather than
> attribute DOMString foo[]; 
> (which is what the spec currently uses)

Will fix. Is that what the WebIDL specify today?>

> * Options.timeout is defined twice, with different descriptions; note
> that the type that should be kept is "unsigned long"

Will fix

> * Error.PERMISSION_DENIED has a numeric value of 0 — isn't it a bit
> dangerous to use 0 as a value since it is equivalent to false? The
> PositionError interface in Geolocation only uses strictly positive
> Values

If this is the case then there are several place where numeric values starting at
0 will have to start at 1. Is this what this WG agree to do? 

For instance we have:

interface StorageUnitAttributes : SystemProperty {
    const unsigned short TYPE_UNKNOWN = 0;
    const unsigned short TYPE_HARDDISK = 1;
    const unsigned short TYPE_FLOPPYDISK = 2;
    const unsigned short TYPE_OPTICAL = 3;
    const unsigned short TYPE_FLASH = 4;
    attribute unsigned short type;
    attribute boolean        isReadWrite;
    attribute unsigned long  capacity;
    attribute unsigned long  availableCapacity;
    attribute boolean        isRemoveable;
};

Should TYPE_UNKNOWN starts at 1?

> * in the 1st example under 4.8 Sensors, I suggest adding a comment that
> "setColorScheme" is a user-defined function or something along that line
> — some readers will assume this is also defined in the spec.

Yes, this will clarify it as user function

> * StorageUnitAttributes.isReadWrite is a boolean - it means it doesn't
> allow to distinguish read-only from write-only storages? (actually, the
> description seems to imply that the attribute really means
> "isNotReadyOnly", but even that is not entirely clear)

Ok, maybe I will change this to "isWritable"? What do you think?

> * KeyboardAttributes.type and KeyboardAttributes.isHardware don't seem
> to be orthogonal; a virtual keyword can typically present a full
> keyboard or just a keypad

Yes, a virtual keyboard (software keyboard) can be a full keyboard or keypad 
and the values return would be KeyboardAttributes.type = TYPE_KEYBOARD and 
KeyboardAttributes.isHardware = false. Is there some thing wrong with this?

Thank you
Dzung Tran

Received on Thursday, 27 May 2010 13:58:50 UTC