[foaf-protocols] WebID pre-alpha specification (uses RDFa)

[Reto Bachmann-Gmür]

Why I think we should have a MUST level requirements for the pasing
side and a SHOULD level requirement for the providing side (as in my
branch): I argued in my previous mail to Henry why the requirement for
the verify agent should not be a SHOULD. For the Web-Id provider
things I think are different, its well imaginable than in future
another format is generally (not just for web-ids) more accepted than
rdf/xml and rdfa while content negotiation may not be easily available
on all servers that can be used to provide web-ids, in this situation
it might be a reasonable to choice to compromise interoperability with
some rare old verifying agents (as in practice modern agents go beyond
the requirements of the web-id spec and support the new format) in
favour of having the personal profile document available in this new
format.

Cheers,
Reto

On Wed, Jul 14, 2010 at 4:55 PM, Reto Bachmann-Gmür
<me at farewellutopia.com> wrote:
> On Wed, Jul 14, 2010 at 3:39 PM, Henry Story <henry.story at gmail.com> wrote:
>
>> Well if we have a standard a bit more generic that would allow us to transform
>> any syntax into semantics, then we would not even need to specify the format.
>>
>> I don't believe it to be impossible that we should reach such a state. Using mime
>> types, name spaces and some convention for finding an extractor of a document's semantics, it is quite possible to see that we could end up in a situation where
>> this could be done automatically.
>
> That's perfectly possible, we could omit everything format specific,
> foaf+ssl woul work between agents that can find a way to exchange rdf
> graphs. HTTP offers what we need for client and server to find the
> best format for communication.
>
> While I think a serialization format neutral protocol has advantages
> in terms of elegance especially when the dominance and general of
> formats changes, I believe the advance of guaranteeing
> interoperability solely assuming the parties speak http(s) is more
> important with the current state of development of the semantic web.
>
>> So as we don't want to wait for this world, we pragmatically specify a couple
>> of formats parsers SHOULD support.
>
> I think this is a bad compromise. SHOULD requirements mean according
> to rfc2119 "that there may exist valid reasons in particular
> circumstances to ignore a particular item, but the full implications
> must be understood and carefully weighed before choosing a different
> course.". A typical usage would be something like "Clients SHOULD
> inform the user if ..." this rule might be valid in most cases but
> particular situations might make the application objectively better if
> it violates the SHOULD-level requirement.
>
> No I agree that its enough to specify that a webid SHOULD be
> dereferenceable either as RDF/XML or a HTML+RDFA but I think the
> requirement for the consumer should be a MUST.
>
> When would a situation be that an application ants to choose a
> different course and thus be a reason for a SHOULD in the
> specification?
> - In a future situation a new format is supported by virtually all
> web-ids out there and the costs for additionally supporting rdfa and
> rdf/xml are high
> -  (forgot...)
>
> I think its unlikely that either the resources of future machines or
> the available libraries will make a it too high burden for
> implementors to support the two formats.
>>
>> We should just help distinguish the semantics from the syntactic issues IMHO. But this can just be done sytlistically.
>
> The specification should help implement compliant agents, compliance
> with the protocol should guarantee interoperability, this distinction
> - an be it just stylistical - unnecessarily increases complexity.
>
> Both leaving out serialization formats completely (talk about them
> only in the primer) or specifying some formats that must be supported
> (and thus basing the protocol on a lower level of abstraction) are in
> my opinion valid options. But the specification should provide a
> concise definitions of what it mandates, either the distinction of
> semantic and syntactic issues is irrelevant (you don't have to grok
> it, as long as your implementation passes the test suite) or the
> syntactic issues are left out (referencing to http content negotiation
> and other standards but without any normative assertion, neither
> SHOULD nor MUST - in this case you either have to grok it or use a
> platform that cares about it such as Apache Clerezza ;) ).
>
> Reto
>
>
>>
>> Henry
>>
>>
>>>
>>>>
>>>> This will make it easy for future developers, protocol enhancers to understand which parts can be altered if say the situation changes, and some other format becomes even more widespread. Of course by that time a legacy will have been established, which will need to be taken into consideration.
>>>
>>> Its pointless to keep the protocol underspecified for interoperability
>>> not to break compatibility with possible future version. Essential is
>>> to provide a minimum set of mandatory rules that guarantees
>>> interoperability now.
>>>
>>> reto
>>
>>
>