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/