use of DTD in draft-ietf-vcarddav-carddav-06, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

use of DTD in draft-ietf-vcarddav-carddav-06, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Julian Reschke
Hi,

a few comments with respect how draft-ietf-vcarddav-carddav-06 uses DTD
fragments for defining the CardDAV related elements:

1) Section 2.2 (XML Namespaces and Processing) should be expanded to
include statements about how the DTD fragments are to be understood,
similar to Section 2 in draft-ietf-vcarddav-webdav-mkcol-04.

2) The XML spec reference needs to be updated to W3C.REC-xml-20081126,
just as in draft-ietf-vcarddav-webdav-mkcol-04. (Note I'd recommend to
use a shorter reference name, such as just "XML".

3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>)
parse the DTD fragments for me (to do that just markup the artwork with
the proper type of "application/xml-dtd", then use rfc2629xslt's
extract-artwork.xslt
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork>).

A minor issue I found is that at least one element type definition
(addressbook) appeared multiple times; this is not really a problem as
long as they all say the same thing.

On the other hand, address-data has three different definitions (see
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>),
depending on the context it's used in. I think this really should be
avoided. The simplest fix for this seems to just use three distinct names.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] use of DTD in draft-ietf-vcarddav-carddav-06, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

Cyrus Daboo-2
Hi Julian,

--On March 12, 2009 2:41:39 PM +0100 Julian Reschke <[hidden email]>
wrote:

> 1) Section 2.2 (XML Namespaces and Processing) should be expanded to
> include statements about how the DTD fragments are to be understood,
> similar to Section 2 in draft-ietf-vcarddav-webdav-mkcol-04.

Fixed - I re-wrote section 2 to be more like the other draft. The separate
sub-section on XML processing was removed as a result.

> 2) The XML spec reference needs to be updated to W3C.REC-xml-20081126,
> just as in draft-ietf-vcarddav-webdav-mkcol-04. (Note I'd recommend to
> use a shorter reference name, such as just "XML".

Reference updated. I am just using the xml2rfc default for <?rfc
symrefs="yes"?>.

> 3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>) parse
> the DTD fragments for me (to do that just markup the artwork with the
> proper type of "application/xml-dtd", then use rfc2629xslt's
> extract-artwork.xslt
> (<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-a
> rtwork>).
>
> A minor issue I found is that at least one element type definition
> (addressbook) appeared multiple times; this is not really a problem as
> long as they all say the same thing.
>
> On the other hand, address-data has three different definitions (see
> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>)
> , depending on the context it's used in. I think this really should be
> avoided. The simplest fix for this seems to just use three distinct names.

Well we did have calendar-data in CalDAV do the same. I am OK with making a
change if others think it is worth doing.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] use of DTD in draft-ietf-vcarddav-carddav-06, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

Julian Reschke
Cyrus Daboo wrote:
> ...
>> 2) The XML spec reference needs to be updated to W3C.REC-xml-20081126,
>> just as in draft-ietf-vcarddav-webdav-mkcol-04. (Note I'd recommend to
>> use a shorter reference name, such as just "XML".
>
> Reference updated. I am just using the xml2rfc default for <?rfc
> symrefs="yes"?>.
> ...

Yep. xml2rfc's default IMHO is wrong, and results in bad readability.

Here's a replacement:

<reference anchor="XML"
target="http://www.w3.org/TR/2008/REC-xml-20081126/">
   <front>
     <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
     <author initials="T." surname="Bray" fullname="Tim Bray">
       <organization>Textuality and Netscape</organization>
       <address>
         <email>[hidden email]</email>
       </address>
     </author>
     <author initials="J." surname="Paoli" fullname="Jean Paoli">
       <organization>Microsoft</organization>
       <address>
         <email>[hidden email]</email>
       </address>
     </author>
     <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M.
Sperberg-McQueen">
       <organization>W3C</organization>
       <address>
         <email>[hidden email]</email>
       </address>
     </author>
     <author initials="E." surname="Maler" fullname="Eve Maler">
       <organization>Sun Microsystems</organization>
       <address>
         <email>[hidden email]</email>
       </address>
     </author>
     <author initials="F." surname="Yergeau" fullname="Francois Yergeau">
       <organization/>
     </author>
     <date day="26" month="November" year="2008"/>
   </front>
   <seriesInfo name="W3C" value="REC-xml-20081126"/>
</reference>

>> 3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>) parse
>> the DTD fragments for me (to do that just markup the artwork with the
>> proper type of "application/xml-dtd", then use rfc2629xslt's
>> extract-artwork.xslt
>> (<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-a
>> rtwork>).
>>
>> A minor issue I found is that at least one element type definition
>> (addressbook) appeared multiple times; this is not really a problem as
>> long as they all say the same thing.
>>
>> On the other hand, address-data has three different definitions (see
>> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>)
>> , depending on the context it's used in. I think this really should be
>> avoided. The simplest fix for this seems to just use three distinct
>> names.
>
> Well we did have calendar-data in CalDAV do the same. I am OK with
> making a change if others think it is worth doing.

I think in the long term the right approach would be not to use DTD
fragments anymore, and to use RelaxNG instead.

But while we're using DTDs, I absolutely recommend to use them in a way
so that at least in theory they can be used. One alternative approach
would be to use "ANY", and put all the remaining restrictions into prose.

That being said, it seems to me that adding more specific elements
actually would make the vocabulary easier to understand.

BR, Julian