Field separators, again
Nathan D. Bowen
nbowen+yadis at andtonic.com
Wed Jun 8 02:54:20 PDT 2005
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
> 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
If so, which are the specific platforms we're worried about?
More information about the yadis