[oslc-core] Configuration Reporting Subteam - RPE Progress

Arthur Ryman ryman at ca.ibm.com
Wed May 28 11:35:19 EDT 2014


Dragos,

It looks like you are using abbreviated RDF/XML. Where did you get the 
schema? Did you create it? The problem with abbreviate RDF/XML is that it 
is not predictable. There are many possible abbreviations and orders of 
elements.

Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   Dragos Cojocari/Romania/IBM at IBMRO
To:     Arthur Ryman/Toronto/IBM at IBMCA@IBMGB, 
Cc:     reporting-workgroup at mailman.hursley.ibm.com, 
oslc-core at open-services.net
Date:   05/28/2014 11:26 AM
Subject:        Re: Configuration Reporting Subteam - RPE Progress


Hey Arthur,

>>> The schema for non-abbreviated RDF/XML is not very useful. What do you 
think? Would it be consumable?
For very simple resources the schema is not that bad and allows immediate 
access to the configuration information.



>>> Perhaps the best way forward is for RPE to start consuming RDF, and 
using RDF2XML mapping to produce consumable XML?
This is the better solution going forward and we could refactor our REST 
v2 driver to use R2XML to consume RDF data sources. Actually we have such 
a driver but what we still need is to change the "Resource Shape -> XSD" 
process we now use to use R2XML as well.

Regards,
        Dragos




From:   Arthur Ryman/Toronto/IBM at IBMCA
To:     Dragos Cojocari/Romania/IBM at IBMRO@IBMGB, 
Cc:     reporting-workgroup at mailman.hursley.ibm.com, 
oslc-core at open-services.net
Date:   2014-05-28 06:20 PM
Subject:        Re: Configuration Reporting Subteam - RPE Progress


Dragos,

I don't think we should require the use of Reportable REST for 
configuration resources.

I was going to suggest that OSLC recommend that service providers support 
non-abbreviated RDF/XML so RPE could consume configuration resources. 
However, after thinking about it more, this wouldn't solve the problem 
since RPE also requires an XML Schema. The schema for non-abbreviated 
RDF/XML is not very useful. What do you think? Would it be consumable?

Perhaps the best way forward is for RPE to start consuming RDF, and using 
RDF2XML mapping to produce consumable XML?

Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)






From:   Dragos Cojocari/Romania/IBM at IBMRO
To:     Arthur Ryman/Toronto/IBM at IBMCA, 
Date:   05/27/2014 07:37 AM
Subject:        Configuration Reporting Subteam - RPE Progress


Hey Arthur,

I am not able to join the call today due to offline appointments I made to 
prepare for Innovate so I will provide my update here:

1. We have successfully made and end to end test of configuration aware 
document generation with RPE 1.3 and RQM 5.0.2. Example PDF documents, 
slides showing the process outline as well as a 4 minute video documenting 
the entire process are available here:
https://jazz.net/jazz04/resource/itemName/com.ibm.team.workitem.WorkItem/46027

For the tests I have used the SSE PLE image prepared for Innovate.  There 
are a few bugs in the QM version I used for the demo but they are fixed in 
the RQM dev stream.

2. The configuration information is interesting for the docgen scenario. I 
expect that report authors will often want to include in the document 
details on the exact configuration used ( see the PDFs I generated).  For 
this example I created an XSD schema for the OSLC representation of the 
configuration but we need to standardize the Configuration resources and 
see if this information should be made available through the Reportable 
REST APIs.

Regards,
        Dragos





More information about the Oslc-Core mailing list