W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 15 Oct 2003 19:13:55 +0200
To: "Stanley Guan" <stanley.guan@oracle.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEBGINAA.julian.reschke@gmx.de>

> 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
> to validate the message.  RFC 2518 didn't dictate whether the recipient
> 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
> be ignored by the recipient from the same security consideration.  XML
> spec says SchemaLocation only provides a hint, an implementation can
> rightfully ignore the information provided by the sender.


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

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 13:14:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC