QSD description for DAV:contains in DAV:basicsearchschema

[Javier Godoy-2]

Julian,

Section 5.19.8 of draft-reschke-webdav-search-14 requires that "All optional
operators that are supported MUST be listed in the DAV:operators element.
The listing for an operator consists of the operator (as an empty element),
followed by one element for each operand. The operand MUST be either
DAV:operand-property, DAV:operand-literal or DAV:operand-typed-literal
(...)"

But the optional operator DAV:contains cannot be described in these terms,
because
its content model is defined to be (#PCDATA) and there is no operand
descriptor for #PCDATA content.

Is there any conforming way of describing DAV:contains?

IMHO, a possible solution would be defining a "DAV:operand-pcdata" element,
so the following construct would be valid:

  <opdesc xmlns='DAV:'>
    <contains/>
    <operand-pcdata>
  </opdesc>


Regards,

Javier

[Julian Reschke]

Javier Godoy wrote:

>
> Julian,
>
> Section 5.19.8 of draft-reschke-webdav-search-14 requires that "All
> optional operators that are supported MUST be listed in the
> DAV:operators element. The listing for an operator consists of the
> operator (as an empty element), followed by one element for each
> operand. The operand MUST be either DAV:operand-property,
> DAV:operand-literal or DAV:operand-typed-literal (...)"
>
> But the optional operator DAV:contains cannot be described in these
> terms, because
> its content model is defined to be (#PCDATA) and there is no operand
> descriptor for #PCDATA content.

That's correct.

I just checked why I didn't catch this when I implemented QSD in my
server, and of course it's because it doesn't supports DAV:contains.

> Is there any conforming way of describing DAV:contains?

One could argue that the character data isn't a "positional" parameter,
and thus doesn't need to be listed (kind of weak, I agree). That would
make it:

<opdesc xmlns=":DAV"><contains/></opdesc>

> IMHO, a possible solution would be defining a "DAV:operand-pcdata"
> element, so the following construct would be valid:
>
>  <opdesc xmlns='DAV:'>
>    <contains/>
>    <operand-pcdata>
>  </opdesc>

I just tried that, but it would require some cleanup in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.8>
-- do you want propose text for that?

Otherwise I'd propose to stick with the simpler proposal; describe it in
one sentence, and add it to the example in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.9>.

BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:

> Javier Godoy wrote:
>>
>> Is there any conforming way of describing DAV:contains?
>
> One could argue that the character data isn't a "positional" parameter,
> and thus doesn't need to be listed (kind of weak, I agree). That would
> make it:
>
> <opdesc xmlns=":DAV"><contains/></opdesc>
>

This is simple (and less intrusive than adding "operand-pcdata"), but it is
also ambiguous because an operator accepting character data would be
described as if it had a void signature.

If this approach is adopted, it must be worded carefully. Would it be an
exceptional rule for handling DAV:contains? If it is not, it might imply
that *any* operator described in QSD allows character data (or mixed
content!), when actually it is a particular case.

Well... this is not a problem with DAV:contains, because it is already
defined as allowing character data, and overloading it with a void signature
makes no sense. However, general-purpose clients may use the information
provided in the QSD response (when the server supports this feature) for
allowing users to specify additional operators and/or validate the requests
prior to submission. Therefore, when describing other implementation-defined
operators, it might be useful to provide different representations for each
case. For instance, suppose there is an extension operator similar to
DAV:is-collection:

<!ELEMENT is-principal EMPTY >

If it is described as

<opdesc xmlns=":DAV" xmlns:F="http://example.com/foo">
 <F:is-principal/>
</opdesc>

it could be (mis)understood as

<!ELEMENT is-principal (#PCDATA) >

Which clearly is not the intent.

>> IMHO, a possible solution would be defining a "DAV:operand-pcdata"
>> element, so the following construct would be valid:
>>
>>  <opdesc xmlns='DAV:'>
>>    <contains/>
>>    <operand-pcdata>
>>  </opdesc>
>
> I just tried that, but it would require some cleanup in
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.19.8>

I see... since character data is "non-positional", the proposed
DAV:operand-pcdata element cannot be added to the list of operand types in
5.19.8 (which are defined as sorted according to the corresponding
position).

> -- do you want propose text for that?

5.19.1,  Add:
/*
    <!ELEMENT operand-pcdata   EMPTY>
*/

5.19.8, within first paragraph,

The listing for an operator consists of the operator (as an empty element),
followed by one element for each operand /*, and an optional ocurrence of
DAV:operand-pcdata*/.
The operand MUST be either DAV:operand-property, DAV:operand-literal or
DAV:operand-typed-literal, which indicate that the operand in the
corresponding position is a property, a literal value or a typed literal
value, respectively. /*If  the operator allows character data, then
DAV:operand-pcdata MUST be included once.*/

---

Note: Instead of  "operand-pcdata", it might be named differently (e.g.
"pcdata-allowed"), in order to emphasize it is not a "positional" operand as
the other operand-* are.


Best Regards,

Javier

[Julian Reschke]

Javier Godoy wrote:

>> One could argue that the character data isn't a "positional" parameter,
>> and thus doesn't need to be listed (kind of weak, I agree). That would
>> make it:
>>
>> <opdesc xmlns=":DAV"><contains/></opdesc>
>>
>
> This is simple (and less intrusive than adding "operand-pcdata"), but it is
> also ambiguous because an operator accepting character data would be
> described as if it had a void signature.
>
> If this approach is adopted, it must be worded carefully. Would it be an
> exceptional rule for handling DAV:contains? If it is not, it might imply
> that *any* operator described in QSD allows character data (or mixed
> content!), when actually it is a particular case.

We could consider just to state that DAV:contains is an exception, and
discourage the use of this format for other operators. (We should have
made DAV:contains use DAV:literal, but that's too late now).

> Well... this is not a problem with DAV:contains, because it is already
> defined as allowing character data, and overloading it with a void
> signature
> makes no sense. However, general-purpose clients may use the information
> provided in the QSD response (when the server supports this feature) for

Out of curiosity: have you seen a client using this information?

> allowing users to specify additional operators and/or validate the requests
> prior to submission. Therefore, when describing other
> implementation-defined
> operators, it might be useful to provide different representations for each
> case. For instance, suppose there is an extension operator similar to
> DAV:is-collection:
>
> <!ELEMENT is-principal EMPTY >
>
> If it is described as
>
> <opdesc xmlns=":DAV" xmlns:F="http://example.com/foo">
> <F:is-principal/>
> </opdesc>
>
> it could be (mis)understood as
>
> <!ELEMENT is-principal (#PCDATA) >
>
> Which clearly is not the intent.

Yes.

> I see... since character data is "non-positional", the proposed
> DAV:operand-pcdata element cannot be added to the list of operand types in
> 5.19.8 (which are defined as sorted according to the corresponding
> position).
>
>> -- do you want propose text for that?
>
> 5.19.1,  Add:
> /*
>    <!ELEMENT operand-pcdata   EMPTY>
> */
>
> 5.19.8, within first paragraph,
>
> The listing for an operator consists of the operator (as an empty element),
> followed by one element for each operand /*, and an optional ocurrence of
> DAV:operand-pcdata*/.
> The operand MUST be either DAV:operand-property, DAV:operand-literal or
> DAV:operand-typed-literal, which indicate that the operand in the
> corresponding position is a property, a literal value or a typed literal
> value, respectively. /*If  the operator allows character data, then
> DAV:operand-pcdata MUST be included once.*/
>
> ---
>
> Note: Instead of  "operand-pcdata", it might be named differently (e.g.
> "pcdata-allowed"), in order to emphasize it is not a "positional"
> operand as
> the other operand-* are.

I'd probably try to avoid the term "pcdata" here, because it's a very
XML-DTDish term, as opposed to "characters" as used in the XML Infoset.

BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:

> Javier Godoy wrote:
>>> One could argue that the character data isn't a "positional" parameter,
>>> and thus doesn't need to be listed (kind of weak, I agree). That would
>>> make it:
>>>
>>> <opdesc xmlns=":DAV"><contains/></opdesc>
>>>
>>
>> This is simple (and less intrusive than adding "operand-pcdata"), but it
>> is
>> also ambiguous because an operator accepting character data would be
>> described as if it had a void signature.
>>
>> If this approach is adopted, it must be worded carefully. Would it be an
>> exceptional rule for handling DAV:contains? If it is not, it might imply
>> that *any* operator described in QSD allows character data (or mixed
>> content!), when actually it is a particular case.
>
> We could consider just to state that DAV:contains is an exception, and
> discourage the use of this format for other operators (We should have made
> DAV:contains use DAV:literal, but that's too late now).

+1

I had proposed describing character data as an operand because I though you
were allowing it in any case, with no restrictions.

I consider it would be OK if this "operand" were NOT RECOMMENDED,
allowed only for DAV:contains, because of legacy reasons.


>> Well... this is not a problem with DAV:contains, because it is already
>> defined as allowing character data, and overloading it with a void
>> signature
>> makes no sense. However, general-purpose clients may use the information
>> provided in the QSD response (when the server supports this feature) for
>
> Out of curiosity: have you seen a client using this information?

No, I'm not aware of any client implementing this feature... I think it
could be a good enhancement because the client application is not required
to undestand the semantics of each operator (it is up to the user). Thus, if
the client already deals with some signature (e.g. a single property
operand) it could deal with other operators of the same signature. Of
course, not every client is intended for human consumption, and there are
advantages and disadvantages with this approach...

>> Note: Instead of  "operand-pcdata", it might be named differently (e.g.
>> "pcdata-allowed"), in order to emphasize it is not a "positional" operand
>> as the other operand-* are.
>
> I'd probably try to avoid the term "pcdata" here, because it's a very
> XML-DTDish term, as opposed to "characters" as used in the XML Infoset.

Good choice for natural language, too long for an element name... after all,
pcdata stands for (parsed) character data.

Best Regards

Javier

[Julian Reschke]

Ok...

As a compromise about just stating that DAV:contains is an exception,
and adding a new *element* to QSD, what I have specified is an attribute
on opdesc.

See
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.issue.5.19.8-opdesc-vs-contains>.
Javier, is that ok for you?

BR, Julian

[Javier Godoy-2]

Yes, it is an elegant solution because it is unambiguous and it is quite
diffent from positional operand-* elements, making clear that it applies to
the element as a whole. The new wording in section 5.19.8 seems OK for me.

Note that text below the example in 5.19.9 should be modified. Currently it
says "Of the optional DAV operators, DAV:is-defined and DAV:like are
supported". DAV:contains was added in the latest revision.

Besides, I think the attribute declaration in section 5.19.1 must include
an attribute default, for conformance with W3C REC-xml-20060816
http://www.w3.org/TR/2006/REC-xml-20060816/#attdecls

<!ATTLIST opdesc             allow-pcdata (yes|no) "no" >

Best Regards,

Javier

----- Original Message -----
From: "Julian Reschke" <julian.reschke@...>
To: "Javier Godoy" <rjgodoy@...>
Cc: <www-webdav-dasl@...>
Sent: Monday, February 11, 2008 8:30 AM
Subject: Re: QSD description for DAV:contains in DAV:basicsearchschema

>
> Ok...
>
> As a compromise about just stating that DAV:contains is an exception, and
> adding a new *element* to QSD, what I have specified is an attribute on
> opdesc.
>
> See
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.issue.5.19.8-opdesc-vs-contains>.
> Javier, is that ok for you?
>
> BR, Julian

[Julian Reschke]

Javier Godoy wrote:
>
> Yes, it is an elegant solution because it is unambiguous and it is quite
> diffent from positional operand-* elements, making clear that it applies to
> the element as a whole. The new wording in section 5.19.8 seems OK for me.
>
> Note that text below the example in 5.19.9 should be modified. Currently it
> says "Of the optional DAV operators, DAV:is-defined and DAV:like are
> supported". DAV:contains was added in the latest revision.

Yep. And, as a matter of fact, DAV:is-defined was made required long ago.

> Besides, I think the attribute declaration in section 5.19.1 must include
> an attribute default, for conformance with W3C REC-xml-20060816
> http://www.w3.org/TR/2006/REC-xml-20060816/#attdecls
>
> <!ATTLIST opdesc             allow-pcdata (yes|no) "no" >

Good catch. We have that in more places.

I prefer to make it #IMPLIED though, as this avoids having the XML
Infoset depend on whether the parser used validation or not.

BR, Julian

[Julian Reschke]

Julian Reschke wrote:
>> <!ATTLIST opdesc             allow-pcdata (yes|no) "no" >
>
> Good catch. We have that in more places.
>
> I prefer to make it #IMPLIED though, as this avoids having the XML
> Infoset depend on whether the parser used validation or not.

Just for the record; *testing* the DTD revealed some more issues, fixed
with the latest edits, see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.issue.dtd>.

If nothing else comes up I intend to submit a new draft (-15) early next
week.

BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:
> Subject: Re: QSD description for DAV:contains in DAV:basicsearchschema
>
> If nothing else comes up I intend to submit a new draft (-15) early next
> week.

A short comment about casting literal values:

(Section 5.11)  [[
The comparison evaluates to UNDEFINED if the property value can not be cast
to the specified datatype.
]]

What happens if the property value can not be cast to the specified
datatype?:
- when casting a literal value (DAV:literal) if the property type is known
and the server chooses to treat the literal according to this type,
- when casting typed literal values.

Failing with 422 seems logical, though it is not explicitly stated. IMHO, it
may help to recommend servers not to be lenient about this.

Btw, the uppercase keyword UNDEFINED is never used in the document but in
Section 5.11 ("The comparison evaluates to UNDEFINED"). Should it be UNKNOWN
?

Best Regards

Javier

[Julian Reschke]

Javier Godoy wrote:
> Btw, the uppercase keyword UNDEFINED is never used in the document but
> in Section 5.11 ("The comparison evaluates to UNDEFINED"). Should it be
> UNKNOWN ?

Yes.

Another good catch! Fixing right now.

BR, Julian

[Julian Reschke]

Javier Godoy wrote:

> A short comment about casting literal values:
>
> (Section 5.11)  [[
> The comparison evaluates to UNDEFINED if the property value can not be
> cast to the specified datatype.
> ]]
>
> What happens if the property value can not be cast to the specified
> datatype?:
> - when casting a literal value (DAV:literal) if the property type is
> known and the server chooses to treat the literal according to this type,
> - when casting typed literal values.
>
> Failing with 422 seems logical, though it is not explicitly stated.
> IMHO, it may help to recommend servers not to be lenient about this.
> ...

If the *instance* of the property can not be converted to the requested
type, that expression evaluates to UNKNOWN, as said in 5.11. As such, it
  doesn't make the query itself invalid, and thus no error needs to be
returned.

However, if the DAV:typed-value specified in the query can not be
converted to the desired type, it probably would be good to reject the
query, as in

<lt xmlns="DAV:"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <prop><edits xmlns="http://ns.example.org"/></prop>
   <typed-literal xsi:type="xs:integer">foobar</typed-literal>
</lt>

Did you mean that case?

BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:

>
> Javier Godoy wrote:
>
>>
>> What happens if the property value can not be cast to the specified
>> datatype?:
>> - when casting a literal value (DAV:literal) if the property type is
>> known and the server chooses to treat the literal according to this type,
>> - when casting typed literal values.
>>

Excuse me, I should have written "literal" instead of "property". So my
question is: what happens if the *literal* can not be cast to the specified
datatype?:

> if the DAV:typed-value specified in the query can not be converted to the
> desired type, it probably would be good to reject the query,

I agree. Should this behaviour be RECOMMENDED?

> as in
> <lt xmlns="DAV:"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xmlns:xs="http://www.w3.org/2001/XMLSchema">
>   <prop><edits xmlns="http://ns.example.org"/></prop>
>   <typed-literal xsi:type="xs:integer">foobar</typed-literal>
> </lt>
>
> Did you mean that case?

Yes, and about DAV:literal too, because Section 5.10 says [[
  when operand for a comparison with a property for which the type is known,
it MAY be treated according to this type
]]

Suppose the type of the "edits" property is xs:integer.
If the server ignores its type, the following expression is valid, and it
evaluates to false because  "foobar" may not be a value of e:edits, if the
comparison is performed as if the property were xs:string (default
behaviour).

<eq xmlns="DAV:" xmlns:e="http://ns.example.org">
   <prop><e:edits/></prop>
   <literal>foobar</literal>
</eq>

On the other hand, if the server knows e:edits is xs:integer, and it cast
the literal as xs:integer, the expression will not be not valid and there
will be a casting error (as in the typed-literal example above).

Note that
 <typed-literal xsi:type="xs:integer">foobar</typed-literal>
is likely a client's fault (e.g., it did not validate the literal against
the specified datatype)

In the DAV:literal case, whether the error is a fatal one or it is silently
ignored, depends on how the server handles DAV:literal for that property.
My point of view is that, since the client would have used DAV:typed-literal
if it wanted to force casting, the server MAY invalidate the query, or it
MAY fail as in the typed-literal case...

Does this make sense?


Best Regards,

Javier

[Julian Reschke]

Javier Godoy wrote:
> Excuse me, I should have written "literal" instead of "property". So my
> question is: what happens if the *literal* can not be cast to the specified
> datatype?:
>
>> if the DAV:typed-value specified in the query can not be converted to the
>> desired type, it probably would be good to reject the query,
>
> I agree. Should this behaviour be RECOMMENDED?

Probably.

Currently we say

"A server MUST reject a request with an unknown type."

How about adding:

"A server SHOULD reject a request if the value provided in
DAV:typed-literal can not be cast to the specified type".

I don't believe it makes sense to reject a specific 4xx code here. In
theory most of the spec could be rewritten to use RFC3253/3744
pre/postcondition terminology, but it would be a lot of work, and would
not reflect what's actually implemented?

>> as in
>> <lt xmlns="DAV:"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>   xmlns:xs="http://www.w3.org/2001/XMLSchema">
>>   <prop><edits xmlns="http://ns.example.org"/></prop>
>>   <typed-literal xsi:type="xs:integer">foobar</typed-literal>
>> </lt>
>>
>> Did you mean that case?
>
> Yes, and about DAV:literal too, because Section 5.10 says [[
>  when operand for a comparison with a property for which the type is known,
> it MAY be treated according to this type
> ]]
>
> Suppose the type of the "edits" property is xs:integer.
> If the server ignores its type, the following expression is valid, and it
> evaluates to false because  "foobar" may not be a value of e:edits, if the
> comparison is performed as if the property were xs:string (default
> behaviour).
>
> <eq xmlns="DAV:" xmlns:e="http://ns.example.org">
>   <prop><e:edits/></prop>
>   <literal>foobar</literal>
> </eq>
>
> On the other hand, if the server knows e:edits is xs:integer, and it cast
> the literal as xs:integer, the expression will not be not valid and there
> will be a casting error (as in the typed-literal example above).
>
> Note that
> <typed-literal xsi:type="xs:integer">foobar</typed-literal>
> is likely a client's fault (e.g., it did not validate the literal against
> the specified datatype)

Yes.

> In the DAV:literal case, whether the error is a fatal one or it is silently
> ignored, depends on how the server handles DAV:literal for that property.
> My point of view is that, since the client would have used
> DAV:typed-literal
> if it wanted to force casting, the server MAY invalidate the query, or it
> MAY fail as in the typed-literal case...
>
> Does this make sense?

5.10 currently says:

"In comparisons, the contents of DAV:literal SHOULD be treated as
string, with the following exceptions:

- when operand for a comparison with a DAV:getcontentlength property, it
SHOULD be treated as an integer value (the behavior for non-integer
values is undefined),
- when operand for a comparison with a DAV:creationdate or
DAV:getlastmodified property, it SHOULD be treated as a date value in
the ISO-8601 subset defined for the DAV:creationdate property
([RFC4918], Section 15.1).
- when operand for a comparison with a property for which the type is
known, it MAY be treated according to this type."

The second case probably should be aligned with the first one (->
undefined). I think we say "undefined" because servers were known to
behave differently, and it didn't seem important to mandate a consistent
behavior for broken queries.

As you noticed, the third case is special as it's outside the client's
control. Thus, the query should not be rejected, and the expression
evaluate to FALSE or UNKNOWN. As UNKNOWN would have undesirable effects
when combined with other expressions, FALSE seems to be right. Would
that be ok?

BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:

> How about adding:
>
> "A server SHOULD reject a request if the value provided in
> DAV:typed-literal can not be cast to the specified type".

+1


> I don't believe it makes sense to reject a specific 4xx code here. In
> theory most of the spec could be rewritten to use RFC3253/3744
> pre/postcondition terminology, but it would be a lot of work, and would
> not reflect what's actually implemented?

I think this work is worthwhile, but, if current implementations are a
concern, pre/postcondition should not be added at this late stage.

> 5.10 currently says:
>
> "In comparisons, the contents of DAV:literal SHOULD be treated as string,
> with the following exceptions:
>
> - when operand for a comparison with a DAV:getcontentlength property, it
> SHOULD be treated as an integer value (the behavior for non-integer values
> is undefined),
> - when operand for a comparison with a DAV:creationdate or
> DAV:getlastmodified property, it SHOULD be treated as a date value in the
> ISO-8601 subset defined for the DAV:creationdate property ([RFC4918],
> Section 15.1).
> - when operand for a comparison with a property for which the type is
> known, it MAY be treated according to this type."
>
> The second case probably should be aligned with the first one (->
> undefined).

+1


> I think we say "undefined" because servers were known to
> behave differently, and it didn't seem important to mandate a consistent
> behavior for broken queries.

Not a consistent behaviour, but at least one that either does not make up a
broken query as if it were successful, or (as the first case does) states
that some errors may be ignored and the client will not be warned, then it
should verify the request unless it is comfortable with the possible
outcome.


> As you noticed, the third case is special as it's outside the client's
> control. Thus, the query should not be rejected,

Agree, unless a precondition were used, but, as you said above, it might be
inconvenient to do so.

Case A: the server supports DAV:typed-literal. It may be lenient about
errors when casting DAV:literal, because DAV:typed-literal may be used for
asserting that no casting error ocurred.
There is no need for rejection in this case, and allowing DAV:literal to be
casted does not add expression power

Case B: the server does not support DAV:typed-literal, then DAV:literal is
the only resort, no matter whether the client cares about server-dependent
casting failures. Casting is useful because of the same reason. Rejection
would be a problem because automated clients would be confused about the
rejection cause.


> and the expression
> evaluate to FALSE or UNKNOWN. As UNKNOWN would have undesirable effects
> when combined with other expressions, FALSE seems to be right. Would that
> be ok?

IMHO, FALSE is right *only* when the operator is DAV:eq. If the literal is
not casted, the negated expression (<not><eq> .... ) evaluates as TRUE,
which is right too. If the literal were casted and the expression evaluates
to FALSE, the result would not depend on the server's behaviour.

However, if the comparison uses other comparison operator (such as DAV:lt)
and the literal is not casted, it will evaluate as either TRUE or FALSE
according to the property value (xs:string comparison). If the literal is
casted and the expression evaluates to FALSE, then NOT <lt>...</lt>
evaluates to TRUE, meaning that e:edits is greater or equal than "foobar",
when treated as xs:integer... but <gte>...</gte> evaluates as FALSE!

 <lt xmlns="DAV:" xmlns:e="http://ns.example.org">
   <prop><e:edits/></prop>
   <literal>foobar</literal>
 </lt>

This inconsistency seems to indicate that something is wrong with this
approach... Instead, the expression should have been evaluated to UNKNOWN,
which is consistent with DAV:literal being dependent on the server behavior
(although DAV:eq may evaluate to FALSE, since it is harmless).

Alternatively, the server may cast the literal only if it is possible. If
the literal cannot be casted to the property type, then xs:string should be
used.

How is this issue handled by current implementations?


Best Regards

Javier

[Julian Reschke]

Javier Godoy wrote:
>> "A server SHOULD reject a request if the value provided in
>> DAV:typed-literal can not be cast to the specified type".
>
> +1

Done.

>> The second case probably should be aligned with the first one (->
>> undefined).
>
> +1

Done.

>> and the expression
>> evaluate to FALSE or UNKNOWN. As UNKNOWN would have undesirable effects
>> when combined with other expressions, FALSE seems to be right. Would that
>> be ok?
>
> IMHO, FALSE is right *only* when the operator is DAV:eq. If the literal
> is not casted, the negated expression (<not><eq> .... ) evaluates as
> TRUE, which is right too. If the literal were casted and the expression
> evaluates to FALSE, the result would not depend on the server's behaviour.

Correct.

> However, if the comparison uses other comparison operator (such as
> DAV:lt) and the literal is not casted, it will evaluate as either TRUE
> or FALSE according to the property value (xs:string comparison). If the
> literal is casted and the expression evaluates to FALSE, then NOT
> <lt>...</lt> evaluates to TRUE, meaning that e:edits is greater or equal
> than "foobar", when treated as xs:integer... but <gte>...</gte>
> evaluates as FALSE!
>
> <lt xmlns="DAV:" xmlns:e="http://ns.example.org">
>   <prop><e:edits/></prop>
>   <literal>foobar</literal>
> </lt>
>
> This inconsistency seems to indicate that something is wrong with this
> approach... Instead, the expression should have been evaluated to
> UNKNOWN, which is consistent with DAV:literal being dependent on the
> server behavior (although DAV:eq may evaluate to FALSE, since it is
> harmless).
>
> Alternatively, the server may cast the literal only if it is possible.
> If the literal cannot be casted to the property type, then xs:string
> should be used.
>
> How is this issue handled by current implementations?

The one I implemented tries to cast, but if it's not possible compares
string representation. I think that's consistent with the grammar; the
client did not ask for a typed comparison, after all.

The "MAY do typed comparison" case mainly is for those servers that know
about property types, but do not support DAV:typed-literal.

So it seems we should change

"when operand for a comparison with a property for which the type is
known, it MAY be treated according to this type."

to

"when operand for a comparison with a property for which the type is
known and when compatible with that type, it MAY be treated according to
this type."

Feedback appreciated,

Julian

[Javier Godoy-2]

Julian Reschke wrote:

>
> The one I implemented tries to cast, but if it's not possible compares
> string representation. I think that's consistent with the grammar; the
> client did not ask for a typed comparison, after all.
>
> The "MAY do typed comparison" case mainly is for those servers that know
> about property types, but do not support DAV:typed-literal.
>
> So it seems we should change
>
> "when operand for a comparison with a property for which the type is
> known, it MAY be treated according to this type."
>
> to
>
> "when operand for a comparison with a property for which the type is known
> and when compatible with that type, it MAY be treated according to this
> type."

+1, I think it is clear and concise.

Even though rejection was never allowed for DAV:literal, the former text did
not state an explicit behaviour for type incompatibilities. Now, by
disallowing casting when the DAV:literal values are not compatible with the
property type, the possibility of casting errors disappears.

It follows that the server MUST accept it and do its best (for instance, it
may treat the property as xs:string for that expression, or it may do so for
each occurence of the property within the search condition).


Best Regards,

Javier

[Julian Reschke]

Javier Godoy wrote:
> +1, I think it is clear and concise.
> ...

OK, please review at:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.10>
or below:

"5.10.  DAV:literal

    DAV:literal allows literal values to be placed in an expression.

    White space in literal values is significant in comparisons.  For
    consistency with [RFC4918], clients SHOULD NOT specify the attribute
    "xml:space" (Section 2.10 of [XML]) to override this behavior.

    In comparisons, the contents of DAV:literal SHOULD be treated as
    string, with the following exceptions:

    o  when operand for a comparison with a DAV:getcontentlength
       property, it SHOULD be treated as an integer value (the behavior
       for non-integer values is undefined),

    o  when operand for a comparison with a DAV:creationdate or DAV:
       getlastmodified property, it SHOULD be treated as a date value in
       the ISO-8601 subset defined for the DAV:creationdate property (see
       [RFC4918], Section 15.1; the behavior of values not in this format
       is undefined).

    o  when operand for a comparison with a property for which the type
       is known and when compatible with that type, it MAY be treated
       according to this type.

5.11.  DAV:typed-literal (optional)

    There are situations in which a client may want to force a comparison
    not to be string-based (as defined for DAV:literal).  In these cases,
    a typed comparison can be enforced by using DAV:typed-literal
    instead.

    <!ELEMENT typed-literal (#PCDATA)>

    The data type is specified using the xsi:type attribute defined in
    [XS1], Section 2.6.1.  If the type is not specified, it defaults to
    "xs:string".

    A server MUST reject a request with an unknown type.  It SHOULD
    reject a request if the value provided in DAV:typed-literal can not
    be cast to the specified type.

    The comparison evaluates to UNKNOWN if the property value can not be
    cast to the specified datatype (see [XPATHFUNC], Section 17)."





BR, Julian

[Javier Godoy-2]

Julian Reschke wrote:

> OK, please review at:
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.10>

Quite good for me.


Best Regards,

Javier