The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
Version |
Location |
Description |
Submitted by |
Date submitted |
|
https://library.oreilly.com/book/9780596004217/relax-ng/304.xhtml
Last paragraph (Example) |
In the Examples for xsd:positiveInteger it says:
Valid values include [...], 1, and [...].
Invalid values include [...] and 1.
This probably should have been "-1" as an invalid value.
|
Burkart Lingner |
Aug 28, 2015 |
Other Digital Version |
xsd:hexBinary
Example |
On page books.xmlschemata.org/relaxng/ch19-77143.html which relates this book example is incorrect (invalid byte order). It causes misunderstanding in HexBin implementation due result from code is differ from example in book.
It seems, author incorrectly converts data. And it is problem because this link is first in Google for HexBin query.
Detailed question and answer here stackoverflow.com/questions/63575873/hexbinary-byte-order
|
Anonymous |
Aug 25, 2020 |
|
15
First Patterns section, outline |
I'm confused about the outlining format Using spaces below to represent outline levels via indendation, why is it formatted such that the document has
- one library element
- one or more author elements
- zero or more character elements
When the author and character are elements of book, not library? Was it just because the elements would have been formatted difficult to read in print? It seems like everything below "an isbn element composed of text" should have been starting at the same levle as "an isbn element composed of text" for clarity?
|
Anonymous |
Jul 31, 2015 |
PDF |
Page 87
1st para after list |
Replace
> "[...] which represent IEEE simple (32 bits) and double (64 bits)
> precision floating-point types."
with
> "[...] which represent IEEE "single precision" (*binary32*, 32 bits)
> and "double precision" (*binary64*, 64 bits) floating-point types."
or similar, because:
- The names were *single precision* and *double precision* in IEEE 754:1985, but not **"simple"** precision.
- The two types are now called *binary32* rps *binary64* in the current IEEE 754:2008 standard.
Referencing the pertaining standard could also be helpful, the official designation is "IEEE Std 754-2008, IEEE Standard for Floating-Point Arithmetic" as far as I can tell.
This applies to the text mentioning "defined by the IEEE" on page 416 and 420 too. Note that the terms "single" (or "simple") and "double" precision are not used there, which is a good thing.
|
tin-pot |
Dec 26, 2015 |
PDF |
Page 87
1st para after list |
The text states:
> "These datatypes accept several special values: positive zero ( 0 ),
> negative zero ( –0 ) (which is less than positive 0 but greater than
> any negative value); [...]"
In fact, positive zero (0, or +0) and negative zero (-0) are *required to compare equal*, as both the 1985 edition and the current 2008 edition of IEEE 754 clearly state:
> "Comparisons shall ignore the sign of zero (so +0 = −0)"
I do not know of any programming language or interchange format specification which does violate this requirement in the actual or specified semantics of binary floating-point values.
|
tin-pot |
Dec 26, 2015 |
Printed |
Page 97
4th line of compact syntax sample |
The translation from xml to compact syntax for the library sample associate the following declaration (p 95):
<attribute name="available">
<data type="boolean"/>
</attribute>
to :
attribute available {xsd:boolean "true"}
same on page 100
|
Jean-Luc Martinez |
Jun 12, 2009 |
Printed |
Page 143
para 4, starting 'here again' |
says, 'are substituted to the orginal'
suggest it should be
'used instead of the definitions in library.rnc'.
|
Anonymous |
|
Printed |
Page 441
bottom |
xsd:short ? 32-bit signed integers
should read:
xsd:short ? 16-bit signed integers
|
Anonymous |
Jan 19, 2010 |