Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)

Julian,

If you're just looking for a schema language for the *formal notation*,
then any choice will be fine with me :-).

Let me try my best for these questions:

> OK, so *how* do you express the following rules in XML Schema?
>
> - in addition to the specified child elements, *any* other element is
> allowed (at any position!), unless it's specified in RFC2518,

I think, what you need here is
   <xs:any namespace="##other" processContents="lax"/>
specified in a "choice" component.

A question here: if the server claims that it only supports "versioning",
but not "acl", is it an error if the user sends  a request to find the
"DAV:acl" property?

>
> - 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.

>
> - ordering is irrelevant

"choice" is the best candidate.  "all" is somewhat limited.

Best,

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 10:13 AM
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)


> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan
> > Sent: Wednesday, October 15, 2003 6:52 PM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)
> >
> >
> >
> > Julian,
> >
> > Thank you for your comments.
> >
> > Personally I'm working on the implementation of XML Schema. So, I'm
> > talking more from the XML Schema perspective.  Sorry for the bias. See
> > my response below.
>
> Ok :-)
>
>
> > Yes, it matters only on how recipients use the DTD, or possible other
> schemas,
> > to validate the message.  RFC 2518 didn't dictate whether the recipient
> should
> > use DTD, XML Schema, or Relax NG to validate the XML message.  Right?
>
> Right. And it doesn't need to. The recipient can of course validate the
> message with any technology it feels adequate. To be adequate, it must
> somehow be able to express the special WebDAV extensibility rules.
>
> > If the schema is provided by the sender, say using SchemaLocation, it
> should
> > be ignored by the recipient from the same security consideration.  XML
> Schema
> > spec says SchemaLocation only provides a hint, an implementation can
> > rightfully ignore the information provided by the sender.
>
> Correct.
>
> > In this case, I was thinking of hardwiring the schema to the recipient.
>
> That's fine.
>
> > I'm not a big fan of XML Schema either.  But, I think XML Schema WG is
> > trying hard to correct some of the problems in its original design.
> However,
> > managing namespaces is a big concern.  Current approach for new
extensions
> > is just extending DAV: namespace.  This introduces a versioning control
> > issue.
>
> Such as...? Fact is, one of the most successful XML applications --
XSLT --
> uses *exactly* the same extensibility mechanism as WebDAV. If a schema
> language isn't able to express this kind of extensibility mechanism,
that's
> unfortunate but it doesn't necessarily mean that the mechanism itself is
> flawed.
>
> I don't want to change WebDAV. In fact, we can't change WebDAV unless we
go
> back to "proposed standard", and it's very unlikely that at this point of
> time, we'd get big players such as Microsoft to update their code.
>
> So what this issue is about is to *keep* the current extensibility rules
> while considering a better (hopefully formal) way to express them in the
> spec. DTDs can't do that well, nor can XML Schema. Relax NG may be able to
> do it.
>
> > Currently, DAV extensions are using XML structures in a limited way.
> > To handle these structures, I think, XML Schema can provide good
> > support for its constraint specification and address
> > extensibility by using
> > its "extension" or similar mechanisms.  What I'm trying to say here is:
> > TRUE, the whole XML Schema spec. is hard to read; but, if you carefully
> > enough to use a subset of its features, it's still a good tool for
message
> > validation.
>
> OK, so *how* do you express the following rules in XML Schema?
>
> - in addition to the specified child elements, *any* other element is
> allowed (at any position!), unless it's specified in RFC2518,
>
> - arbitrary properties are allowed
>
> - ordering is irrelevant
>
> As far as I understand, XML Schema can't do that (as the extensibility
rules
> explicitly allow new child elements from the DAV: namespace).
>
> > Lastly, XML Schema has been widely supported by most software
> > vendors.
>
> I don't want to see another xml-dev permathread migrating here. We just
need
> the schema language for the *formal notation*. It's completelely
irrelevant
> here whether it is or will be implemented.
>
> What *is* relevant is whether we can find a notation that is better suited
> for writing the spec. I seriously doubt that XML Schema can be a candidate
> (if only for it's verboseness).
>
> > ...
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>

Received on Wednesday, 15 October 2003 14:05:49 UTC