RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...)

Hi Julian and Stanley,

I have been watching your discussion with interest.  I concur that XML Schema should work just nifty for DAV, and the one case of concern to me can be handled, with a little care.

Let me summarize:

1.	XML Schema is able to assess schema validity for documents that have arbitrary elements (and attributes) from other namespaces.  I see there is an open question on the occurrence of arbitrary attributes on DAV elements and that needs to be looked at separately (e.g., how to use attributes from the global attribute namespace versus ad hoc attributes piled onto the DAV element and the element-local namespace -- and whether the second should be ever allowed).

2.	I agree that XML Schema is not an useful way to specify DAV elements and their content models in the body of the specification. However, having and using XML Schemas for DAV XML documents is still an useful option.

3.	The case of concern for me is that XML Schema assessment can be done without doing anything to the document, as Stanley noticed.  

3.1	There is no requirement to provide an xsi:schemaLocation list, and there is also no requirement that the XML processor use it.  It's all hinting, as I recall.

3.2	However, XML Schemas are targeted to namespaces (which is how the whole document can be assessed for schema conformity even when the document is drawn from many namespaces).  Since DAV does not use immutable namespaces, but uses an extensible namespace with a single namespace URI (DAV:), this means the schema definition has to be updated when new official elements are added.  

3.3	The only wrinkle here is that XML processors that do schema assessment tend to cache the XML Schema definitions by namespace URI.  So when the DAV namespace is given new local names, any processor prepared to accept those and provide appropriate schema assessment must update its cache with the new schema definition.  (This is another reason that namespace versioning is useful, but ... that's life [;<).  [I think my schema/DTD-validating XML editor requires me to flush the whole cache to do that, and that's the price I pay for being so picky.]

The datatype model of XML Schema seems to be gaining popularity for establishing and expressing the (lexical) datatype of simple-element content too.  So there is already a source of data-type tags (and new schema-defined ones) that can be supplied as attributes of property elements conveyed in DAV <prop> listings [;<).

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan
Sent: Wednesday, October 15, 2003 13:41
To: Julian Reschke; w3c-dist-auth@w3.org
Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)



Julian,

See my comments inline!

Thx,

-Stanley

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Stanley Guan" <stanley.guan@oracle.com>; <w3c-dist-auth@w3.org>
Sent: Wednesday, October 15, 2003 11:32 AM
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)


[ ... ]

>
> Last time was dicussed I was told that this will not allow new extension
> elements from the DAV: namespace.

True.  But, new DAV extension elements should be explicitly listed in
the "choice" component.  So, any bogus element in DAV: namespace
can be caught.

[ ... ]
>
> > > - arbitrary properties are allowed
> >
> > I think, you can collect all server supported DAV: properties in
> > a single complexType using "choice" component.  Then, using
> > "extension" component to extend different capabilities into the
> > final set.
>
> Sorry. I wanted to say "attributes".

I thought we want to be loose on what can be allowed at element
level.  Within each element, don't we want all attributes to be
explicitly spelt out?  Why do we need arbitrary attributes to be
allowed on any specific DAV: element?

If elements belong to the following category:
   <xs:any namespace="##other" processContents="lax"/>,
then any arbitrary attributes can be allowed in them.

[ ... ]

Received on Wednesday, 15 October 2003 19:01:30 UTC