[Osr-101] Neutron specs

[Thomas Comiotto]

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.


>
> 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!

>
> 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!*

>
> (Note that my example above does not take into consideration the 
> unique identification of resources, but could simply be added by e.g.
>
> <resource name="Some Document" uid="/document"/>

The identifier is needed to resolve references to the resource. If we 
want to use xi:include directives for that we either have to use uri or 
urn + resolver catalog to make it work. Or we introduce your own custom 
directives - I'd rather not..

>
>
>> Checkout is a shortcut of open + lock. I am still not convinced re 
>> this shortcut when considering servers with exclusive/shared locks. I 
>> don't think it makes sense but Michi does, well..
>
> Let's simply supply all of them, but make it clear what checkout and 
> checkin mean.
>

Agreed.


>> To make two more points re considering content editable/read-only: 
>> Ulysses for instance provides a "save to local filesystem" function - 
>> so every retrieved document is considered editable. And, Neutron is a 
>> content authoring protocol so the implied usecase is to edit.
>
> 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. Maybe we have to start another thread to discuss this with our 
marketing hats on:)


>
>>>> you mean that Neutron could also be placed on top of other 
>>>> protocols than just HTTP?
>>>
>>> Of course. But this can also be acomplished using the format we are 
>>> using now, because the scheme part of the URI basically defines the 
>>> protocol. Using the format above, we had to introduce "*Method" 
>>> attributes for every protocol a user could potentially be interested 
>>> in.
>>>
>> Agreed. But I wanted to make the point that not every protocol uses 
>> the semantics of a "method", therfore "method" implies using a scheme 
>> that supports it, HTTP for instance. Anyway that's minor issue:)
>
> 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......

--
Bests
Thomas