> This is exactly the right time to start playing with extensions. I  
> have not tried at all yet.
> (in part because it seems like the most clearly badly designed part  
> of atom - and the thought of all
> this wasted time because ... ok I'll stop the rant right here.)

>> [snip]
>> <a:link rel="replies" href="foo" thr:count="10" xmlns:thr="urn:foo" />

>> #1 is not that bad:

>>  :link [ a :Link;
>>            :rel iana:alternate ;
>>            :to [ :src <http://example.org/>;] ;

>>           thr:count "10"; # notice JS extension
>>            ];

> is thr:count a real extension btw? Do we have good examples for  
> this?  You probably by now have a list of good extensions.

> I suppose in the end we will never be able to formulate a general  
> rule to know if people put extension there if the extension is meant  
> to go on the :Link object or on the :Content object it points to.

> By the way this could be an argument for making Link just simply  
> opaque so that all :Link objects always appear like
> this

> :link [ a :Link;
>          :href <http://eg.com/e1.html>;
>          :rel iana:alternate;
>          :type "text/html";
>          thr:count "10";
>        ] .

> here we would be very close to the syntax.

> Of course having something that simplifies things the way we have now  
> is really nice too. But I am worried that we may be trying to improve  
> atom.

> So keep this in mind as you work with extensions.

>> #2 is where the hill got a little steep:

> reminder to myself: we are dealing with this example:

> <a:id xmlns:x="urn:bar"  
> x:identifierType="lsid">urn:lsid:ex.org:entries:1</a>

>> [snip]
>> Now we can go into the extension attributes...

>> [] :id [
>>     rdf:value "urn:lsid:ex.org:entries:1"^^xsd:anyURI
>>     x:identifierType "lsid" ;
>>     random:property  "randomValue" .
>> ] .

> By the way I wonder how this compares to using owl:sameAs .

> [] :id [ owl:sameAs "urn:lsid:ex.org:entries:1"^^xsd:anyURI;
>           x:identifierType "lsid" ;
>           random:property  "randomValue" ] .

>> x:identifierType rdfs:type atom:extensionAttributeProperty;
>> atom:extensionAttributeProperty rdfs:subClassOf rdf:Property .

>> Now because of atom:extensionAttributeProperty we can figure what
>> extension attributes to attach back to the original element.

> ok.

>> Now onto extensions.

>> atom:extension rdfs:type atom:extensionElementProperty;

>> <a:entry>
>> <gd:when startTime="2005-06-06" endTime="2005-06-07"
>>        valueString="This weekend"/>
>> </a:entry>

>> [ :extension "<gd:when startTime="2005-06-06" endTime="2005-06-07"
>>        valueString="This weekend" xmlns:gd="http://schemas.google.com/g/
>> 2005"
>> />"^^rdf:XMLLiteral .
>> ]

> Yes. I agree. This is what one has to do, unless one is given some  
> indication as to the meaning of the extension.
> In which case one could process it and extract the meaning as a set  
> of tri

>> Luckily, the only two things we need to pass to extension elements:
>> xml:lang and xml:base and those can easily be added (unless there's a
>> conflict, but that's another hill to climb and we're not there yet  
>> since
>> we can only climb on hill at a time).

>> Now in case someone brings up the I would like to query the name of  
>> the
>> extension (local and/or ns) etc, I would like to push that off to  
>> SPARQL
>> and a XPath extension against the XMLLiteral.

>> Additionally, we could support :simpleExtension.

>> <a:entry>
>> <s:when>Today</s:when>
>> </a:entry>

>> [
>>    s:when "Today" .
>> ] .

>> s:when rdf:type atom:simpleExtensionElementProperty .
>> atom:simpleExtensionElementProperty rdfs:subClassOf rdf:Property .

> Yes. That looks good.

>> Regards,

> Looks like a really good start. Would you like to write up a little  
> section for the html version explaining this? Perhaps a little  
> further down the road when things have settled a bit (or before to  
> help you think about them).

>> Ben, Lee and I.