> The remaining question is when is data correct or incorrect.
Clearly there are different ways of defining this. One way is that data is
correct if it matches the state of the real world (if the data says my date
of birth is 13 Nov 1980, it is incorrect). I was using the term "bad data"
to mean "data that violates the assumptions that my query/stylesheet makes
about what constitutes good data". In general this is a stricter requirement
than "valid according to a schema/DTD" since there are many constraints that
cannot be expressed in a schema or DTD - not only cross-document
constraints, but also contextual constraints (a date must be in the future)
and constraints that are too complex to express in a given schema language
(e.g. if @x=1 then @y must be present).
> If there is a schema (XSchema,DTD) against which it is to be
> validated, then I would tend to define data as correct if and
> only if it validates correctly. If there is no schema, data
> is correct if it is well-formed.
>
> The above document is well-formed and (if you agree) correct data.
>
> I don't see anything wrong with the following query:
>
> for $p in document("p.xml")//person
> where $p/@age = 3
> return $p/@name
>
> Why should it fail?
I think you have found a bug. I don't think this query should fail simply
because the untyped attribute @age contains a value that cannot be converted
to a double. I think the comparison should return false. My colleagues may
disagree; but certainly, if this fails, it is a nasty incompatibility with
XPath 1.0.
Michael Kay