Re: [orms] ORMS Design Principles

[Tatsuki Sakushima <tatsuki@nri.com>]

(5/6/10 8:11 PM), Nat Sakimura wrote:
> (2010/05/07 3:16), Tatsuki Sakushima wrote:
>> I thought that it was useful to have design principles among TC members.
>>
>> I wrote some of them as what I hoped for ORMS in the wiki. Please update yours or argue against mine.
>>
>> http://wiki.oasis-open.org/orms/DesignPrinciples
>>
>> ----
>> 1. It only defines "framework". (relationship among elements. Also see Principal #3.)
>>    -The users define the context and how to use.
>>    -It is a markup language(XML) to write reputation data.
>>    -No score format, normalization and representation. (Users should define those.)
>>   
> For portability, I think we need some kind of normalization or
> interpretation guideline, IMHO.

I thought that normalization and interoperability were profile specific.
If we could successfully define a universal set for reputation data like Atom/RSS, 
we are responsible for normalization and interop. 

If we think of elements like <Score> and <Data>, it will be hard to get agreement on 
standard sets(types) of those. The universal definition seems to be difficult to provide.
Therefore, I came up with the user-definable and markup language way.

With this design, normalization and interop are part of context defined by data provider 
who is responsible for the context.

Data providers may be responsible for stating what this data means, how to verify etc
under the context, but may not for normalization. 
Data users may be responsible for normalization. How to use and present data may be up to them. 

>> 2. Transport is out of scope.
>>    -However, it assumes REST API(HTTP GET) to be used for retrieving this document(data).
>> 3. It keeps the structure simple.
>>    -No more than 2 layers in hierarchy. (3 layers with <ReputationBundle>)
>>    -Only 7 elements are defined. (excluding ds:Signature)
>>     -<Reputation>, <Context>, <Subject>, <Assertion>, <Score>, <ReputationBundle>, <Date>
>>    -It avoids defining a group element if possbile.
>>    -It avoids defining unnecessary schema(elements, attributes).
>>    -It avoids defining unnecessary data types. (e.g. id values since URI is identifier.)
>> ----
>>
>>   
> 
>