OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

orms message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ORMS Design Principles


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.)
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.)
----

-- 
Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]