Interim WebDAV WG mtg notes - 1/20/03

  The following notes were taken on the first day of the interim WebDAV 
working group meeting held 20 Jan, 2003. There are undoubtedly portions 
of the discussion that were not recorded, my apologies for the 
occasional ommision. If anyone recalls things that I have missed, please 
mention them.

Elias
_____________________________

Julian Reshke led the following discussion on datatypes for WebDAV 
properties

The basic idea is that a PROPFIND would provide type information for 
dead and non-RFC2518 live properties. PROPATCH would similarly allow one 
to specify data types in conjunction with setting property values.

The approach uses the W3C XML schema type library and instance type 
attribute to indicate types. This has the advantage of using a standard 
and extensible type library (also used in many other vocabularies).

(Lisa Dusseault) It would be desirable to add information the the 
OPTIONS response to indicate whether the server supports this. Further, 
a PROPATCH response should indicate whether or not the type attribute 
was recognized by the server.

Additional property information to be considered includes:
* 'hidden' flag
* 'protected' flag
* 'display name' attribute

Open issues to be resolved:
* marshaling of display name
* relationship to document types and schema definitions of required 
property sets

Are we ready to think about schema definitions of property sets? of 
resources allowed in collections?

There was a general acknowledgment that this would primarily affect 
DASL, but would likely have some impact on othe WebDAV specs as well.

Two types of questions this proposal would address are "I want to create 
a resource, what properties do I need to set?" and "I have a resource, 
how do I treat the values of properties?"

As an example of a possible approach to server implementation, it was 
noted that Sharepoint allows any resource to be put into a typed 
collection and then  checks the type constraints when a CHECKIN is done. 
Another option would be to do type checking upon an UNLOCK...

General discussion brought up the following concerns (paraphrased):

Is the proposal sufficient fo DASL?
How does this work with PROPFIND allprop?
What are the driving requirements?
Should this be a WG item then? (general approval)
Should we then link its progress to the DASL spec?
Should it also be connected with schema discovery?
Another related topic is schema registration.

General discussion on how best to proceed lead to a concensus on 
initially developing the high-level requirements, then move further 
discussion to a separate (new) mailing list.
---
ACL discussion led by Lisa Dusseault and Eric Sedlar

Lisa Dusseault presented feedback received from the IESG on ACL:
* Basic authenticaiont over SSL/TLS is a MUST level requirement
* Methods should be mapped to specific permissions (in a table)
* Flexibility in te secification is a source of risk. Humans will err 
and poorly written clients will help them.

Eric Sedlar then led further discussion on the spec.

The semantics of ordering wrt granting/denying permissions needs to be 
worked out. Proposal to use the NFSv4 approach. Also need to specify how 
custom priveleges are expressed.

The spec will be clearer and easier to implement correctly if the 
language is stronger - use MUST level requirements wherever possible.

<I missed recording some of the discussion at this point>

(Lisa Dusseault) Can we make it explicit in the spec that we are making 
no attempt to map ACL to *nix permissions. Also moved to drop the 
informational RFC from the WG milestones.

(Jim Whitehead) Should we specify what is returned when tere is an ACL 
problem? We should constrain what is possible.

(Lisa Dusseault) 404 MUST be returned if the client doesn't have read 
permission, and 401/403 otherwise.
---

Dennis Hamilton led the following discussion on property registration.

There is a recognized need to record authoratative info on properties 
and namespaces such as where to go (spec., company, etc.) for more 
detail. There is also a desire to reduce the complexity of the spec as 
much as possible.

The focus of this effort is not machine-readable discovery of 
properties, but future work may address this.

On namespace registration and authority:
* Namespaces SHOULD be registered and
* namespaces SHOULD be resolvable.
* Just anyone should not be able to register a property within a given 
namespace.

(Julian Reschke) This problem exists across all XML efforts...

(Dennis Hamilton) We can likely refer to oter docs or source of 
information on this issue and make sensible recommendations where 
appropriate.

(Jim Whitehead) Someone needs to make a list of questions that we want 
to know the answers to about WebDAV properties. Host this example 
documet on webav.org after its complete.
---

DASL discussion led by Julian Reschke.

Current issue list:
* Error marshaling
    - proposal to align the sepc with RFC3253
* 'next n' results
* type handling in query literals
    - proposal to add DAV:typed-literal operad carrying xsi:type attribute
* language handling for queries on txt props
    - proposal not to do this
* Collation sequence for text comparisons

On 'next-n' results:
(Julian Reschke) Previous discussion on list about persisting search 
results to a URL.

(Jim Whitehead) How is this currently done with DBs?

(Erc Sedlar) Depends on the DB, some save state, some redo te query and 
throw away the first n results.

<some discussion on implementation> Summary: Next n results is something 
we want in the spec, no clear agreement on how best to implement it. 
There are issues related to authentication and caching search resiults 
to be explored as well.

(EricSedlar) Caching is crucial in large repositories, just getting the 
first results back can be expensive.

General agreement that servers should be allowed to generate static 
results at some URL, but should not be required to do so.

(Lisa Dusseault) It is possible to use the range header for getting m-n 
results..


On type handling:

QSD needs to handle DAV:typed-literal.

(Jim Whitehead) Would making QSD a MUST help this issue?

Concensus reached among those attending to add DAV:typed-literal and 
make QSD a MUST level requirement.


On language handling: (Summary)
If a user wants a language sensitive comparison, then they should 
specify that with a language operator. Spoec. should be silent on this 
when discussing other operators. Those in attendance agreed this is the 
case.


On collation sequence:

(Jim Whitehead) The Unicode documet that generaaly covers this issue is 
not complete. It may not be a valuable use of time to try and do better.

(Eris Sedlar) Collation in DBs can be set with lang+territory but has 
impact on performance, and one may need multiple indices.

(Lisa Dusseault) Java allows a collation to be specified, shouldn't be 
dificult to implement [in java].

(Julian Reschke) Intend to use language from XPath/XQery, allowing lang 
to be passed in and a URL to refer to collation info.

Proposal to change nae of casesensitive comparison operator to 
caseinsensitive, which describes the behavior more accurately. No 
objections from those present.

On dates:
(Julian Reschke) Would support using only ISO dates in DASL spec.

(Lisa Dusseault) RFC2518 only supported other format for compatibility 
with RFC2616.

There was an extended discussion on typing of operands vs. typing of 
operators - further discussion pushed back to list as no concensus could 
be reached. We need a thorough comparison to make any decision.

On error marshaling:
General concensus to follow RFC3253 approach/definitions.

Other items:
(Jim Whitehead) What does lte mean? can we be more specific in te spec?

Why is the use of "_ _" prohibited in a query? It shouldn't be a problem 
to implement. The like syntax should conform to SQL'92 definition.

Discussion and agreement among those present that ordering on 
mixed-content is undefined.

(Eric Sedlar) The contains operator should work on properties... it is 
the most frequently used search.

(Julian Reschke) To support that we would need to relax wording in the 
definition of 'contains'.

Maybe extending basicsearch is the correct way to accomplish this?

Julian will be submitting another draft of the DASL spec.

Received on Saturday, 25 January 2003 21:01:29 UTC