Mandatory client supported serializations

Well probably the main reason I wrote that is because it is also to
consider in the choice of mandatory serializations.
So far it seems WebID is set on requiring a more or less random bunch of
serializations based on guessing what mostly the publishers are going to
want to use, which has following aspects:
+ publishers get more freedom of choice
- hard implementing client code
- probably limiting the WebID use by high serialization parsing requirements
- alienating the fans of not chosen seralizations

Now lets consider the alternatives:
2) chooising 1 syntax with low parser requirements (n-triples?)
+ easy to implement client
+ low client implementation requirements
- less choice on publisher side
- alienating the fans of not chosen serializations

3) write the core spec by NOT requiring ANY specific serialization, but
create a separate document specifying a restrictions for creating an
interoperability "trade"mark, which carries all the points of 1) (maybe
lessening the - of alienation) but maintaining the WebID core
serialization agnostic, which is good modularity which avoids the
conflict of interests wanting the WebID to be most open and flexible and
wanting it to be a central piece of reliably interoperable network.

Feel free to add + and - points to the above, I just want to know why is
1) the way WebID is headed, not 3).
I know I am not participant of WebID XG, nor I have any implementation
ready, but I don't think that any of those facts makes my point less
logically valid.

Best,
Jiri

PS: I didn't add the subjective point of supporting the client side is
more important then giving mroe choice to the publishers

On 12/30/2011 07:53 PM, Henry Story wrote:
> 
> On 30 Dec 2011, at 20:42, Jiří Procházka wrote:
> 
>> Hi,
>> I think WebID should be flexible enough to be used on low memory
>> embedded systems, does this put any restrictions on the mandated
>> syntaxes? I figure turtle because of prefixes would be no go, and other
>> syntaxes too - the algorithm for webid validation (client code),
>> including the parsers for all required syntaxes, would be best to have
>> constant space complexity...
>> I don't think such concerns nor the use case are so outlandish they
>> shouldn't be taken in consideration.
> 
> I am trying to keep that in mind and keep in mind development for the freedombox.
> Swap-scala from Dan Connolly seems to indicate that you can write parsers in very little
> space for all the well known serialisations.
> 
>   http://code.google.com/p/swap-scala/
> 
> So there is a lot that can be done I think to reduce the space consumption of tools like Jena.
> 
> Henry
> 
> 
>>
>> Best,
>> Jiri
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> Social Web Architect
> http://bblfish.net/
>