--- CBOR-XS/XS.pm	2013/11/28 15:43:24	1.27
+++ CBOR-XS/XS.pm	2013/11/28 16:09:04	1.28
@@ -28,38 +28,31 @@
 
 =head1 DESCRIPTION
 
-WARNING! This module is very new, and not very well tested (that's up
-to you to do). Furthermore, details of the implementation might change
-freely before version 1.0. And lastly, most extensions depend on an IANA
-assignment, and until that assignment is official, this implementation is
-not interoperable with other implementations (even future versions of this
-module) until the assignment is done.
-
-You are still invited to try out CBOR, and this module.
-
 This module converts Perl data structures to the Concise Binary Object
 Representation (CBOR) and vice versa. CBOR is a fast binary serialisation
-format that aims to use a superset of the JSON data model, i.e. when you
-can represent something in JSON, you should be able to represent it in
-CBOR.
+format that aims to use an (almost) superset of the JSON data model, i.e.
+when you can represent something useful in JSON, you should be able to
+represent it in CBOR.
 
-In short, CBOR is a faster and very compact binary alternative to JSON,
+In short, CBOR is a faster and quite compact binary alternative to JSON,
 with the added ability of supporting serialisation of Perl objects. (JSON
 often compresses better than CBOR though, so if you plan to compress the
-data later you might want to compare both formats first).
+data later and speed is less important you might want to compare both
+formats first).
 
 To give you a general idea about speed, with texts in the megabyte range,
 C<CBOR::XS> usually encodes roughly twice as fast as L<Storable> or
 L<JSON::XS> and decodes about 15%-30% faster than those. The shorter the
 data, the worse L<Storable> performs in comparison.
 
-As for compactness, C<CBOR::XS> encoded data structures are usually about
-20% smaller than the same data encoded as (compact) JSON or L<Storable>.
-
-In addition to the core CBOR data format, this module implements a number
-of extensions, to support cyclic and self-referencing data structures
-(see C<allow_sharing>), string deduplication (see C<pack_strings>) and
-scalar references (always enabled).
+Regarding compactness, C<CBOR::XS>-encoded data structures are usually
+about 20% smaller than the same data encoded as (compact) JSON or
+L<Storable>.
+
+In addition to the core CBOR data format, this module implements a
+number of extensions, to support cyclic and shared data structures (see
+C<allow_sharing>), string deduplication (see C<pack_strings>) and scalar
+references (always enabled).
 
 The primary goal of this module is to be I<correct> and the secondary goal
 is to be I<fast>. To reach the latter goal it was written in C.
@@ -73,7 +66,7 @@
 
 use common::sense;
 
-our $VERSION = 0.09;
+our $VERSION = '1.0';
 our @ISA = qw(Exporter);
 
 our @EXPORT = qw(encode_cbor decode_cbor);
@@ -261,7 +254,7 @@
 a code reference that is called with tag and value, and is responsible for
 decoding the value. If no entry exists, it returns no values.
 
-Example: decode all tags not handled internally into CBOR::XS::Tagged
+Example: decode all tags not handled internally into C<CBOR::XS::Tagged>
 objects, with no other special handling (useful when working with
 potentially "unsafe" CBOR data).
 
@@ -358,7 +351,7 @@
 Tagged items consists of a numeric tag and another CBOR value.
 
 See L<TAG HANDLING AND EXTENSIONS> and the description of C<< ->filter >>
-for details.
+for details on which tags are handled how.
 
 =item anything else
 
@@ -371,8 +364,8 @@
 =head2 PERL -> CBOR
 
 The mapping from Perl to CBOR is slightly more difficult, as Perl is a
-truly typeless language, so we can only guess which CBOR type is meant by
-a Perl value.
+typeless language. That means this module can only guess which CBOR type
+is meant by a perl value.
 
 =over 4
 
@@ -380,7 +373,7 @@
 
 Perl hash references become CBOR maps. As there is no inherent ordering in
 hash keys (or CBOR maps), they will usually be encoded in a pseudo-random
-order.
+order. This order can be different each time a hahs is encoded.
 
 Currently, tied hashes will use the indefinite-length format, while normal
 hashes will use the fixed-length format.
@@ -391,15 +384,18 @@
 
 =item other references
 
-Other unblessed references are generally not allowed and will cause an
-exception to be thrown, except for references to the integers C<0> and
-C<1>, which get turned into false and true in CBOR.
+Other unblessed references will be represented using
+the indirection tag extension (tag value C<22098>,
+L<http://cbor.schmorp.de/indirection>). CBOR decoders are guaranteed
+to be able to decode these values somehow, by either "doing the right
+thing", decoding into a generic tagged object, simply ignoring the tag, or
+something else.
 
 =item CBOR::XS::Tagged objects
 
 Objects of this type must be arrays consisting of a single C<[tag, value]>
 pair. The (numerical) tag will be encoded as a CBOR tag, the value will
-be encoded as appropriate for the value. You cna use C<CBOR::XS::tag> to
+be encoded as appropriate for the value. You must use C<CBOR::XS::tag> to
 create such objects.
 
 =item Types::Serialiser::true, Types::Serialiser::false, Types::Serialiser::error
@@ -525,7 +521,7 @@
      my ($self) = @_;
      my $uri = "$self"; # stringify uri
      utf8::upgrade $uri; # make sure it will be encoded as UTF-8 string
-     CBOR::XS::tagged 32, "$_[0]"
+     CBOR::XS::tag 32, "$_[0]"
   }
 
 This will encode URIs as a UTF-8 string with tag 32, which indicates an