Object vs string representation of arguments (Re: Mozilla/Cisco API Proposal)

On 07/12/2011 09:23 PM, Chou, Wu (Wu) wrote:
>
> The discussion on using string or JS object is helpful. However, it 
> should be done after we have established a commonly agreed data model 
> for RTC web, or for a particular function, e.g. media description.
>
> The data model should define elements, relations, semantics, and 
> extensibility using some formal language, e.g. UML, XML etc., that 
> covers all use cases.
>
> A data model specification, e.g. UML, XML, etc., allows developers to 
> verify their implementations agnostically. In addition, the data model 
> can be imported or modified from other established standards or 
> communication protocols.
>
> After the establishment of the data model, we can be at a position to 
> look into the binding issue to HTML, e.g. either as object or using 
> string. Moreover, we can evaluate the pros and cons of each approach 
> in a concrete setting, as these are purely binding issue after the 
> establishment of the data model.
>
> Without an agreed data model, things are entangled, e.g. ICE, SDP, 
> state, extensibility, etc., many of them belong to data model not on 
> binding and sterilization to JS.
>
I agree that the choice of data model and the choice of data 
representation are somewhat orthogonal.
However, I disagree with sequencing them.

We currently have people doing implementation / experimentation work. 
They need to implement something, and if they are to achieve 
interoperability in the test phase, they have to implement the same 
"something".

After 20 years of doing ad-hoc string parsers (I wrote the first-ever 
ABNF grammar validator), I'm getting tired of making more ad-hoc 
structures for representing lists of values, some of which contain lists 
of values, some of which have special delimiters, some of which have 
different charset limitations to avoid the delimiters, some of which 
have quoting conventions.... and the (high) risk that you impose high 
parsing costs at arbitrary points in your implementation.

JSON objects seem to me like a chance to get an easily definable format 
with enough expressive power and a single, context-independent string 
representation *if* stringifying is needed. For arguments that are more 
than tokens, I want to see a strong argument for why 
yet-another-string-parser is a better choice than a JSON object.

                       Harald