[Accessforall] Minutes of Context .. preference set repn

Colin Clark colinbdclark at gmail.com
Fri Jul 27 21:26:23 UTC 2012


Hi Gerhard,

In this case, we have to wear two different hats: one as the designers of a technology-agnostic specification and information model (AccessForAll/ISO 24751); and the other as the developers of the Cloud4all project.

In the first case, our goal is to create an information model that can be bound to different formats--JSON, XML, text, object models in different programming languages, etc. So we can't mandate the use of XML DTD in this case.

In the second case, we'll be using JSON extensively, so XML DTD probably won't work for us. We have been exploring, however, the use of JSON Schema, a comparable means by which we can validate JSON documents. Here's a recent conversation on the Architecture mailing list between Antranig and Andy Heath on the subject:

http://lists.gpii.net/pipermail/architecture/2012-May/000278.html

I hope this helps,

Colin

On 2012-07-26, at 4:28 AM, Gerhard Weber wrote:

> I'm in favor of simple way to run validation against such statements whenever a human has entered new facts. XML DTD should do.
> Gerhard
> 
> -----Ursprüngliche Nachricht-----
> Von: accessforall-bounces at fluidproject.org [mailto:accessforall-bounces at fluidproject.org] Im Auftrag von Andy Heath
> Gesendet: Donnerstag, 26. Juli 2012 09:02
> An: Gottfried Zimmermann (List)
> Cc: Accessforall at fluidproject. org; sp1 at cloud4all.info; SP2 at cloud4all.info
> Betreff: Re: [Accessforall] Minutes of Context .. preference set repn
> 
> With respect to preference set representation :
> 
>> Sample preference set:
>> 
>> {
>> 
>>   "property":"http://gpii.net/ns/up/fontsize",
>> 
>>   "condition": "",
>> 
>>   "value":"120%"
>> 
>> }
>> 
>> {
>> 
>>   "property":"http://gpii.net/ns/up/fontsize",
>> 
>>   "condition": "value('http://example.com/context/localtime')>=  '18:00'
>> 
>>     && value('http://example.com/context/localtime')<  '22:00'",
>> 
>>   "value":"150%"
>> 
>> }
> 
> Is this just the "human" view ? What's the perspective in cloud4all about the best way to represent this data ?
> 
> I appreciate this might suit xslt processing and mapping to databases and is easy to introduce extra fields into but its a little wasteful - in some cases messages will be twice the length needed.
> For passing between systems and system parts why not scrap the field names and do something like this:
> 
> Instead of:
> 
> [
> {"property": "a", "condition": "b", "value": "c"},
> {"property": "d", "condition": "e","value": "f"} ]
> 
> it could be:
> [
>   {"a": {"b" : "c"} },
>   {"d": {"e" : "f"} }
> ]
> 
> or even
> 
> [
> {"fieldnames": {"property": {"condition": "value" }}}, {"records" : [ {"a": {"b" : "c"} },
>                {"d": {"e" : "f"} } ] }
> ]
> 
> ?
> 
> Cheers
> 
> andy
> --
> __________________
> Andy Heath
> http://axelafa.com
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org



More information about the Accessforall mailing list