Re: The w3c test objects.

Libby Miller wrote:

>
>  
>
>>(A) I have seen these before. Some minor nits:
>>
>> Many of the VALARMs have an ATTACH property that is not valid:
>>
>>        ATTACH;VALUE=URI:Ping
>>
>> Extra CR LF's in them between components.
>>    
>>
>
>Sorry, could you clarify? the ics files in that directory are all
>generated from tools which export iCalendar.
>

Nothing serious, but several of the components end with:

    CR LF CR LF

and not just

     CR LF

I do not know of a parser that can not handle it, but it is not per the 
2445 ABNF.

>> Some VEVENTs have no SUBJECT or DESCRIPTION.
>>
>>    
>>
>
>Descriptions and summaries are optional, as I understand it - is that
>incorrect?
>
Yes incorrect. When they have the METHOD property for example.  See the 
restriction
tables in RFC-2447. For example SUMMARY in a VEVENT PUBLISH is not
optional, but may be empty.

>(B) RDF issues I have noticed in the examples:
>
>  I noticed that the RDF format drops the 'VALUE' parameter completely.
>
>VALUE (as in VALUE=BINARY, VALUE=DATE) is handled in various ways within
>the RDF model.
>So in RDF whether something is text or a uri is a crucial distinction
>handled by the RDF syntax. Whether something is a DATE or a DATETIME is
>handled using different RDF properties.
>
>I think the main thing is that we can roundtrip between the RDF and
>iCalendar versions, so we aren't losing information - inevitably there
>will be differences in the syntactic representation that are difficult
>to explain as we are translating between two different representational
>languages.
>  
>
How do you handle VALUE=x-user-type ?

Example:

    iCAL:

        x-foo-property;VALUE=x-user-type:1234

    RDF:

          ?

>  The RDF-cal has a 'class' tag, that is not the same as the iCAL
>'class' tag.
>
>hm, it's not intended to be different. All we have done is create uris
>to represent the possible values for class, i.e. public, private,
>confidential become
>
><class rdf:resource='http://www.w3.org/2002/12/cal/ical#private'/>
>
>etc
>
>this just fits in better with the way RDF works - it's much better at
>matching URIs than strings.
>
Okay, perhaps because it looked different from the way the other 
property values
were translated I may have missed it. Looking closer...

As it appears that the URL specified is specific to iCAL, why is CLASS 
treated
as a special property type?

>  The examples drop the CLASS property nd its PUBLIC, PRIVATE,
>  and CONFIDENTIAL values completely.
>
>  The RDF-cal does not distinguish between property values and parameters.
>  
>
>
>this distinction doesn't really matter to RDF :)
>We don't think that matters as long as we can get back to the iCalendar
>format as required.
>
Maybe ... still thinking about this.

>  
>
>>  I have yet to see an example of how multivalued values are treated.
>>  Is the XML tag replicated or is the value just put in 'as is'?
>>    
>>
>
>Which properties were you thinking of? If there were (say) two
>descriptions then you would just repeat the tag. I don't think we have
>come across any iCalendar data with repeated tags yet. RDF has an
>underlying model of object->property->object, so the syntax would
>depend on whether the repeated tag translated into an RDF object or
>property.
>

Multi valued means two or more values for ONE property, not the same
property repeated twice. CATAGORIES for example allows one or more
values separated by a comma.

This example is one property with two valules:

    CATEGORIES:BUSINESS,HUMAN RESOURCES

>Thanks again for taking a look at what we've been doing - it's very
>useful to get such detailed feedback from the iCalendar community.
>

And again I think that any WebDAV work should be separate from a 
specification
on translation of date from iCAL from and to XML.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards