1) why we have struct inside the <list> ? 2) How do we query? Xpaths (from input message) 3) Are we trying to do one data model that support both JSON and XML? So each service will have both. If we are OK for JSON or XML model (not both) did we consider the templates oppose to this model? (just thinking aloud. Templates are very clean if it can work)
--Srinath On Tue, Jun 4, 2013 at 6:25 PM, Anjana Fernando <[email protected]> wrote: > Hi, > > Today we had a meeting with Sanjiva, Sumedha, Harshana, Manuranga and > myself. The discussion was the new language changes for DSS 4.0, and also > how some of its features to be used as the general mapping format to be > used in other places in the platform as well, e.g. for the DevStudio data > mapping tool. > > Basically in the new format, in the data service queries, we are going to > make it's input and output data abstract. That is, it will no longer define > XML elements in the result sections, and it will have a generic object > model for the parameters and for the result section. > > So this is basically an intermediate object model populated from the data > received from the data sources, after a specific query is executed, and > this data structure will be serialized into a target wire format, such as > XML, JSON, Thrift and so on, which are defined in the operations and > resource definitions. And also in the same way, the input message will be > converted from the wire format to this intermediate data structure. > > With these functionality, data services can support complex data service > scenarios, such as complex input messages, which contains data for many > aggregated queries, and by supporting the new object model, it can map to > many output types using the same data services query, so we can efficiently > support features like content negotiation. > > Following contains a sample configuration of the format we decided so far > to represent the object model:- > > <struct name="Data"> > <list name="Employees"> > <struct> > <field name="firstName" type="string" /> > <field name="lastName" type="string" /> > <field name="dob" type="dateTime" /> > <list name="nicknames" type="string" /> > </struct> > </list> > </struct> > > Notice the inner struct is anonymous, but it is also possible for a named > struct to be defined globally and it to be reference within another type > definition, like "<list name="Employees" type="Employee">", this is in the > same way it works in XML schema. With this, we can re-use same type > definitions in different queries etc.. > > So basically something similar to above configuration will represent a > data service query parameters section (it doesn't have to be a single > parent item there, it can have multiple root field items), and also, same > type of configuration will be used for the result section as well, and > there will be a separate mapping configuration, which will be used to map > the data results of a query to this object model, that is we have to tell, > how the field "Data.Employees.firstName" will be populated, as in, which > record in the result set will fill that value, this mapping format is still > not decided. I will work on a possible representation on that and update > this thread. > > Cheers, > Anjana. > > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- ============================ Srinath Perera, Ph.D. http://www.cs.indiana.edu/~hperera/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
