Bug: SPARQL 1.1 Query Language / 17.4.1.7 RDFterm-equal

The section specifies RDFterm-equal in an inconsistent way.
Quote:===========================================================
term1 and term2 are the same if any of the following is true:...term1 and term2 are equivalent literals as defined in 6.5.1 Literal Equality of [CONCEPTS]....
===========================================================


Following the link to "6.5.1 Literal Equality" one finds:
===========================================================

6.5.1 Literal Equality
 
Two literals are equal if and only if all of the following hold:
    
   - The strings of the two lexical forms compare equal, character by character.
   - Either both or neither have language tags.
   - The language tags, if any, compare equal.
   - Either both or neither have datatype URIs.
   - The two datatype URIs, if any, compare equal, character by character.
...===========================================================

Note that the text does not define "equivalent literals", but literal equality, and this equality is described as syntactic equality.
However, the section includes an example in which RDFterm-equal returns true in the case of value equality without literal equality:"2004-12-31T19:00:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> xsd:dateTime("2005-01-01T00:00:00Z")A footnote following the example confirms the use of value equality, opposed to syntactic equality:"Invoking RDFterm-equal on two typed literals tests for equivalent values."
Conclusion: the specification of RDFterm-equal is inconsistent, describing it in one place to mean literal equality and in another place to mean value equality.
Additional problem: the sentence from the beginning of the section:
"produces a type error if the arguments are both literal but are not the same RDF term *;"
is quite confusing - 
(a) what is the meaning of the hyphen preceding the semicolon?(b) why should two literals which are not the same RDF term produce a type error, if a boolean assessment of equality is expected(c) the statement is contradicted by both examples where arguments which are literals without equality do not produce a type error. 

Hans-Juergen Rennau