[OSLC-Reporting] Challenges of schemas

[Arthur Ryman]

Joan,

I looked at these posts and they seem quite dated, circa 2006/2007. I 
think we should understand the problem that XSD is being proposed to solve 
in the context of reporting, and then see if there is a better 
alternative.

The proposed use of XSD is as design time information (metadata) that 
describes the XML you get as the reponse of an HTTP GET. This metadata is 
used by tools, e.g. to author a document generation template, or make the 
data look like an ODBC source for ETL definition or report authoring.

We also are making the assumption that service providers will only do a 
little extra work, i.e. they will add some features to their services to 
make reporting work better. It is a good idea to lower the barriers to 
adoption. If we assume that service provides are going to serve up XML, 
then it seems like just a little extra work to serve up some description 
of it. Here are the alternatives:

1. use XSD
2. use another schema language, e.g. RELAX NG, Schematron
3. invent our own OSLC metadata format
4. see if any other group invented a metadata format we could use
5. use a generic sample XML document and infer the metadata
6. work without any metadata - use any reponse as a sample and map it

#6 is feasible if you assume the XML you GET is representative, i.e. it 
contains all the elements and attributes you are interested in. In 
practice, many items are optional so you wouldn't see that in a typical 
response.
#5 overcomes the above difficult by asking for an explicit sample document 
that contains examples of all the relevant items

A related complexity is that the structure of the response may depend on 
the query parameters, i.e. some "required" items may be filtered out, or 
more nested data may be inlined. Of course, we could also solve that by 
requesting the metadata/sample for the URL + query parameters.

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 



<joan.touzet at accenture.com> 
Sent by: oslc-reporting-bounces at open-services.net
11/03/2009 04:59 PM

To
<oslc-reporting at open-services.net>
cc

Subject
[OSLC-Reporting] Challenges of schemas






Here are a few good blog posts about why binding the OSLC-Reporting 
approach to an XSD is potentially shooting ourselves in the foot ? in 
increasing order of exasperation :) That said there is at least one 
argument here that suggests an XSD.
 
http://www.pluralsight.com/community/blogs/dbox/archive/2006/02/17/18869.aspx 

http://blogs.msdn.com/mikechampion/archive/2006/02/23/537640.aspx 
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=ca19f6b9-8afd-4e93-b4f6-8c3beee8d088 

http://www.tbray.org/ongoing/When/200x/2006/02/22/WS-Flurry 
http://www.xmldatabases.org/WK/blog/2287_10_things_to_change_in_your_thinking_when_building_REST_XML_Protocols.item 

http://72.249.21.88/nonintersecting/2006/11/29/they-cant-hear-you/ 
 

Joan Touzet
Accenture  -  Global Delivery Excellence  -  ADS Mobilisation, ADT CoP 
Communications Lead

Phone/FAX 
+1.416.641.3092 (641/13092)
MS OC (text only)
joan.touzet at accenture.com
MSN
JoanTouzetACN at hotmail.com 
AIM/Skype/GTalk 
joantouzetacn
 
This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you have 
received it in error, please notify the sender immediately and delete the 
original. Any other use of the email by you is prohibited.
_______________________________________________
OSLC-Reporting mailing list
OSLC-Reporting at open-services.net
http://open-services.net/mailman/listinfo/oslc-reporting_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-reporting_open-services.net/attachments/20091103/626a6226/attachment-0003.html>