Dan, I must disagree on the "integer issue".
In JavaScript/ECMAScript/JSON, there is only "Number". There is no integer vs float types. No matter how you choose to write it, it's the same "number". I don't think we should try to define a restricted version of JSON, much as your argument for vCard :) As for the "whole channel issue", I suppose we might a statement to the "FCC 2010 Ruleset" section, but I'm not quite sure what the concern is that this resolves? Is the concern that the Database might be returning center frequencies for channels? -vince On Mon, Dec 9, 2013 at 9:18 AM, Harasty, Daniel J <[email protected]>wrote: > PAWS WG, > > > > I’ve been in some discussions where PAWS implementers have stated the > following preferences: > > > > 1. Certain values in PAWS – such as “startHz”, “stopHz”, > “resolutionBwHz”, “powerDbmPerBw” – should be expressed in messages as > integers rather than floats. > > · Example, encode the “startHz” of Channel 43 with the integer > notation “644000000”, rather than floating point notation such as “644e6” > or “6.44e8”. > > · Reason: internal representation of floats are rarely exact, and > equality operations are often complicated by this. > > > > 2. Values such as “startHz” and “stopHz” should be constrained to > actual television channel band edges – at least in the US. > > · Reason: as a practical matter, as there is no concept – at this > time – that the US databases will ever state the availability of “part” of > a US TV channel. > > > > Both afford implementation simplification for the WS devices, and thus I > think they deserve some discussion. Is there a way to address this in the > spec without removing future flexibility, or affecting use cases outside > the US? > > > > Here is one possibility: > > > > A. Address the “integer issue” with language to the effect of: “when > encoding numeric values that are integers, the sender MUST use the JSON > encoding that avoids its representation as a float – that is, it must not > use either the decimal point nor the exponent part”. > > (This is intentionally less draconian than stating that certain values > like “startHz” and “powerDbmPerBw” MUST be integers; rather “when they are > integers, represent them as such”.) > > > > B. Address the “whole channel issue” by adding verbiage to the > meaning of the “FCC 2010 Ruleset” that states expressly that “startHz” and > “stopHz” values must be constrained to actual U.S. television channel band > edges. > > > > Thoughts? > > > > Dan Harasty > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
