Re: utf8u tag proposal

> From: William Spitzak [mailto:[email protected]] 
> Sent: Monday, September 28, 2009 3:16 PM
> Subject: Re: [Yaml-core] utf8u tag proposal
> 
> Osamu TAKEUCHI wrote:
> 
> 
> > So, I vote one to the form "!!utf8u a%b%c" as the canonical form.
> 
> I believe you meant "a%25b%25c". It was also suggested that 
> the canonical form replace *all* bytes with %xx, so it might 
> be "%61%25%62%25%63".

The canonical form was indeed suggested as being "%61%25%62%25%63" to make
it easy to convert to the canonical form. The canonical form doesn't need to
be human readable because it is ~only~ for the YAML processor to use when
checking for equality. In fact, reason will quickly show that because it
used only internally by the YAML processor that the YAML processor doesn't
actually need to use this canonical form at all as long as it performs the
comparison ~as if~ the conversion had been performed. So a YAML processor
can implement this as efficiently as possible by doing what actually needs
done so long as its behavior is correct. For example, a YAML processor could
actually choose to keep the data as UTF-8 for comparison purposes, if it was
able to support that internally. The canonical form is a reference as to how
nodes compare for equality and nothing more. I think that's why Oren didn't
think twice about suggesting that the canonical form be fully expanded like
this.

A canonical form is not the recommended presentation format (the form that
would appear in the YAML file), although it might be the same as the
recommended presentation format. I don't think any of the data types
actually define a "recommended" presentation format (only possible
presentation formats), leaving this up to the YAML processor, which lets it
decide how this can most efficiently be done.

I suspect the motivation behind saying that "a%b%c" should be the canonical
form was that it was being thought of as a recommendation about how the data
type should be presented. That was also my concern when Oren first made his
suggestion and I still worry a little that others might take it that way as
well.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf