Errata

RELAX NG

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