Field separators, again

[Nathan D. Bowen]

Paul Crowley wrote:

> That "provided" is actually my biggest reservation with XML.  A plea 
> to those discussing the issue: please represent it as simple key/value 
> pairs of strings, so there's a direct map between this format and the 
> other formats.

If we're going to start from the premise that we only want to send 
simple key/value pairs of strings, we shouldn't bother discussing XML as 
a possibility -- more on that in a minute, though.

The colon-separated names and values, one per line, would be a 
significant improvement over x-www-form-urlencoded. For simple key/value 
pairs of strings, XML would provide no further benefits, it would just 
use funnier-looking separators and terminators.

But instead of colons, why not use = as the separator? Then, as a bonus, 
we can describe it in terms of its similarity to "Windows INI format" or 
the "Java Properties format".

One other change worth considering is to the names themselves, to make 
the values' meanings more self-evident for future implementors.
I would suggest:
    "dh_public" in place of "dh.gy" (not all Diffie-Hellman 
documentation uses the name 'gy')
    "digest_type" in place of "auth_type",
    "encryption" in place of "enc" (enc looks like 'encoding' to me),
    "encrypted_secret" in place of "enc_secret"

No need to worry about those unless we're sure we'll be using this 
format, though.

> These goals aren't necessarily aligned - agreeing more than one format 
> for the consumer to choose between may actually take longer than 
> agreeing one format.  On the other hand, it makes a holy war between 
> format A and format B impossible.

If we opt out of the question of which single format to use for 
responses, I shudder to think about the question "Why won't you add my 
favorite format, too? After all, I see a format-selection step right 
there in the protocol..."

But why are we focusing only on parsing? There are certainly pros and 
cons of response formats beyond the ease with which they can be parsed.

XML data is almost self-documenting. As long as we don't restrict 
ourselves to simple name/value pairs, XML gives us the opportunity to 
make the response format significantly more declarative and 
understandable. For implementing and testing and learning this stuff, 
would anyone new to the project prefer to find anything other than XML 
-- except for fear of parsing it?

I can't actually think of a real platform that would be useful for 
OpenID on which a little XML parsing would be out of the question. I 
don't remember anyone complaining that XML will be a problem for their 
own platform, I think we've all just been anticipating that complaint.

I don't mind using the "ini" format at all, and I'm sure no one else 
would be too upset over any of these proposals.

But am I right in thinking that XML would be the best choice based on 
its own merits for describing the data (as it has been for so many 
projects that had to weigh similar concerns) -- we're just concerned 
about parsing?

If so, which are the specific platforms we're worried about?