Re: Re: mod_enclosures proposal

Reto Bachmann-Gmuer <[email protected]>
Newsgroups gmane.network.syndication.rss.devel
Message-ID <[email protected]>
Bill Kearney wrote:

>>The statement "http://example.org/apage
>>rdfs:description 'ugly'" may have different truth value for you and me,
>>but if I ever assert it you can expect me not to assert
>>"http://example.org/apage rdfs:description 'beautiful'" at the same time.
>>    
>>
>
>Ah, but you didn't assert it as the same.  Each item was different and it'd
>be entirely reasonable to have your example of a good design example versus
>a bad writing example.
>  
>
If RSS-Files are RDF/XML serializations of RDF models, and not just XML
files that misuses the rdf-namespace, the two statements are in no way
associated with an item, they are statements about the enclosed
document. The fundamental issue is probably: are RSS 1.0 documents just
XML document that happens to pass RDF-Validation without practical use
of it. Or is RSS an RDF vocabulary with some additional requirement on
the serialization for easier transition of pre-RDF tools. I suggest the
second, and suggest to drop the requirements on the serializations
better sooner than the later, as their price is high:
- Generic RDF tools cannot be used to generate valid RSS
- Developers misunderstand RSS as an XML-Format an act accordingly
- Writing extensions is harder because their require both a schema and
serialization instructions
- The growing number of RDF-vocabularies cannot be used without an
additional specification on how to serialize them

>>Exactly, we include images and not particular encoding of images. These
>>are irrelevant, and wherever possible rss-feed should link to the
>>content-type-independent url of the image.
>>    
>>
>
>Unfortunately for you, no part of the spec supports that argument.
>  
>
on the contrary, the rss-spec does not even suggest to include
statements about the content type of an image resource.

>>I see no contradiction
>>between the rss spec and the proposed best practices such as "cool
>>uris", there is of course a gap between currently implemented web and
>>the web designed by w3c recommendations. but just reproducing the
>>existing won't bring us further.
>>    
>>
>Nor will pushing inane examples.  This is perhaps a fundamental reason RDF
>hasn't gained effective traction.  Too many examples of pie-in-the-sky
>theories that are impossible to parse.
>  
>
I think rdf/xml was the higher obstacle for rdf, which led people think
of rdf as some xml-dialect and thus not understand its implications and
using the wrong tools (text editors and xml parsers) for working with it.

>>It was suggested on this list, that RSS should not completely rely on
>>http for content negotiation as there are other protocols for exchanging
>>rss (such as freenet). I agree, but think that the http features should
>>be supported as well, and that http-urls should be usable in the general
>>case and not only when they identify a determined encoding of a resource
>>    
>>
>
>Well, for developers to break out of the "single call to download it all"
>mindset they're going to have to be given reasonble steps to follow.  Giving
>them type data is a much more likely way to encourage uptake than to force
>conneg onto them.  Many of the tools they're using (sad to say) do a
>horrible job of supporting it.  Why raise the bar to such a height as to
>make it impossible for them to try?
>  
>
why not a single call? just add an accept-header if you don't want to
get the default version. The image property in rss does not require a
content-type, a-hrefs in html do not require a content-type, object tags
in html do support it but don't require it, why should this be
compulsory for enclosures? Why shouldn't it just be a normal property
which can be added 0 or n times?

>>So you are saying that "cool uris" are poorly chosen uris because they
>>don't identify the encoding?
>>    
>>
>
>No, that expecting a typed URI will deliver that type and that untyped
>elements aren't terribly useful towards solving the demands the users and
>developers are requesting.  That untyped URI and conneg /could/ be used is
>theoretically possible.  Practical, however, no.
>  
>
users certainly don't want typed urls, they don't care about the format,
the thing should just show up. developers of all browsers and webservers
I know have little problems with http 1.1, but you'll certainly find some.

>>looking at the serializations of rdf-graphs is like looking at text
>>files in binary: please avoid using upper-case so I can easily recognize
>>letter by the trailing '011'.
>>    
>>
>
>Yes well, the tool developers need more than nonsensical replies and
>theories.
>
developer should especially not be left with the illusion that an
XML-Parser is the right to to access RDF Site Summaries.

Reto



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.