[Osr-101] Neutron specs

[Andreas Wuest]

Hi Thomas

On 22.8.2006 22:38 Uhr, Thomas Comiotto wrote:

> Hi Andi
> 
> 
>> Hmm, no, that's not what I meant. What I meant to say is the 
>> following: by providing an <edit> container, a client knows that 
>> whatever is stated in the edit block is regarding editing.
>>
>> If you'd like to have different view configurations of the same 
>> document in question for different purposes, then we could simply add 
>> a <fancynewidea> element, and every <open> endpoint statet therein 
>> implies that if you want to open the document with a configuration 
>> tailored toward that fancynewidea, you should use the open URI 
>> provided in that block.
>>
> 
> Understood and agreed - but not re the example you gave. Different view 
> configurations can easily be achieved by providing different styles for 
> a resource. That's what styling's good for in the end. We have to decide 
> what we want to put into <style> and where introducing a new element 
> related to styling might make sense.

I'm still not convinced. So you are absolutely positive that we would 
never hit a usecase which could not be solved by simply providing a 
different style?

>> On the same token, regarding my first example above, it is really ugly 
>> to have the <edit> and the imaginary <print> element not inside a 
>> common block. After all, following the semantics, we are talking about 
>> them *same* resource, simply delivered by the server with different 
>> configurations. So I'd suggest the following:
>>
>> <introspection>
>>   <resource name="Some Document">
>>     <edit>
>>       <open url="/document?open"/>
>>       <save url="/document?save"/>
>>     </edit>
>>     <print>
>>       <open url="/document?print"/>
>>     </print>
>>   </resource>
>>   <resource name="Some other Document">
>>     ...
>>   </resource>
>> </introspection>
> 
> OK!

Good! :)

>> This is all about scoping and extensibility.
> 
> I am in favor of scoping and I am also in favor of extensibility. 
> *Redundancies are what make me nervous!*

Sure! But I am not trying to introduce redundancies here, I'm just 
trying to think about future usecases which should be as easily 
integrateable as possible.

>> Uhhm, I'd rather call it a content *management* protocol, which does 
>> not only imply editing, but also much more. Of course, this "much 
>> more" still has to be specified.
> 
> Authoring is a very broad term - as is management.. I'd rather consider 
> "content authoring" being more general and therefore better suited that 
> "content management" with regards to Neutron because it does not suggest 
> you need to have a "content management system" in place to use it.

Well, from that POV, this makes sense.

> Maybe 
> we have to start another thread to discuss this with our marketing hats 
> on:)

Heh, I guess so :)

>> Ah, ok, I understand. Yeah, we should find a different name for the 
>> "method" attribute. E.g. something more neutral like "type".
> 
> Not sure here. I'd take the opposite approach and use attribute names 
> that suggest a set of possible values (that's also a bit easier to 
> validate) - or leave it as is......

Uhhm, yeah. But with regard to a specified set of values: wouldn't this 
again limit us with regard to extensibility? I feel that we can't think 
about all the possible protocols people might want to use Neutron with.

Although the introspection document is mainly served via HTTP, the 
actual content might not. Think for example about a CMS which serves its 
content for viewing via normal webpages and HTTP, but they would like to 
use some proprietary protocol to deliver the content for editing etc.

As an easy example, they serve editable documents via a distributed file 
system, e.g. AFS. So what we would end up with in the <open> url would 
be a URI of scheme file. I admit that this example is a bit lame, 
because there you could simply leave "method" unspecified. But OTOH, we 
then also had to take such a case into account when validating, namely 
that "method" MAY be not be present.

-- 
Kind regards,
Andi