Re: "Basic profile" terminology ?

> i'd be really curious whether you're proposing to take pure data-level
> interactions to open scenarios where you have to deal with badly
> implemented and adversarial clients. 

Do tell... let's assume for the moment that your interpretation of the 
proposed direction were correct.  What considerations do the 
badly-implemented/adversarial clients bring in, from your point of view? I 
have ideas of what you MIGHT be hinting at, but until we get concrete it's 
impossible to tell if our thinking is similar, diametrically opposed, etc.

> the service level i am talking about
> is in no way specific to REST, 

If it's not specific to REST, am I to infer that it's at a higher level of 
abstraction?  If so, I'm forced to ask which/whose definition of REST is 
being used in this context; my default choice is "the REST architectural 
style as defined in Roy Fielding's PhD thesis", and if you're operating at 
a higher level of abstraction than "architectural style" I need to 
establish shared vocabulary for me to have any hope of interpreting your 
words as intended.

> it's simply what many different areas of
> communication and data management systems discovered they need for
> robustness and protection. 3-tier architectures are one example for that
> kind of architecture. 

This makes it sound as if you are desirous for "standardization" of 
"things like 3-tier architectures" in this working group, and possibly 
their overlapping/common needs in areas like robustness and protection. Is 
that right?  Are there other aspects on your short list?

> i am definitely coming to this group with a long history and some
> expectations when i hear REST, and one of them is the fact that S is for
> state, meaning that REST is not about implementing CRUD on the HTTP 
level.

If you're saying that RF's thesis definition of REST is at a higher level 
of abstraction than HTTP, sure (plenty of commentary direct from RF on 
that).  I assume you're also aware that by far the most common de facto 
use of the term REST assumes HTTP as a transport and the Web as an 
architecture (hence 1 level down in abstraction from REST-in-RF's-thesis). 
 If this thread is evidence of a model/metamodel discussion mismatch, 
things come into sharper focus for me at least.

> of the main goals is to allow loose coupling by not designing RESTful
> systems in a way where the interactions are based on specifics of the 
data
> model used in the service implementations.

When you say "specifics of the data", I'm guessing (based on some of your 
other comments) that specifics at the media type level would be OK for you 
(it's XML; it's RDF/XML; it's JSON; whatever), and specifics of individual 
vocabularies (Dublin Core, Basic Profile Submission, SIOC, ADMS, whatever) 
would not be OK for you.  Is that a reasonable distinguishing example?  So 
a RESTful system based solely on media types would be considered 
well-designed (loosely coupled) in your parlance, while one based on (in 
RDF terms) recognizing particular predicate URIs' semantic intent would 
not be considered well-designed (loosely coupled)?  That interpretation 
would seem consistent with the one above positing that the "service" 
discussion may be exposing a model/metamodel or "level of abstraction" 
disconnect.




Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario