Jim,

Some clients do cross domains, e.g. our current reporting approach pulls 
data from multiple domains (via ETLs), so cross-domain consistency 
simplifies life. However, I expect most services to provide RDF/XML so in 
practice I don't anticipate a problem. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube







From:
James Conallen <[email protected]>
To:
Tack Tong/Toronto/IBM@IBMCA
Cc:
[email protected], [email protected]
Date:
07/26/2010 01:49 PM
Subject:
Re: [oslc-core] "One last" change to OSLC Core representations
Sent by:
[email protected]



Tack,

I don't think there will be too many clients written that operate with 
different domain specs. Different implementations of the same spec yes, 
but not different domain specifications. Now, if the domain specification 
did not require at least one representation to be supported then yes, your 
concerns are valid. However I think the discussion here is "should all 
core 2.0 derived specifications require one common representation?" In 
this case I don't see the real need. Rather, we _should_ make sure that 
all domain specs require at least one common representation (rdf/xml or 
json for example).


<jim/>

jim conallen
[email protected]
Rational Software, IBM Software Group



Tack Tong ---07/26/2010 12:44:12 PM---+1 for me on Andy's comment. I 
second Samit's concern that unless there is a representation used by

From: Tack Tong <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Date: 07/26/2010 12:44 PM
Subject: [oslc-core] "One last" change to OSLC Core representations
Sent by: [email protected]



+1 for me on Andy's comment.


I second Samit's concern that unless there is a representation used by all
providers, a client writing code would then have to write separate code 
for
each provider, which they could do without OSLC by using the native api of
the provider.

Andy Berner



Tack Tong
IBM Rational software
[email protected]
905-413-3232
tie line 313-3232_______________________________________________
Oslc-Core mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
_______________________________________________
Oslc-Core mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-core_open-services.net




Reply via email to