[Bug 140] New: content (URL) dereference needs explaining (or removing)

[bugzilla-daemon@arjuna.com]

http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=140

           Summary: content (URL) dereference needs explaining (or removing)
           Product: WS-Context
           Version: 1.0
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Text and diagrams
        AssignedTo: ws-caf@lists.oasis-open.org
        ReportedBy: peter.furniss@choreology.com
         QAContact: mark.little@arjuna.com


0.3 offers alternative ways of dereferencing a context-by-reference : the 
ContextManager service described in section 3, or a "URL that
may be dereferenced to resolve the data directly"

Presumably this will usually (always ?) be an http or https url. Some 
unanswered questions are:

1. is the context identifier involved in the dereference ? If so, how ? 
Presumably not, in which case the content uri must itself be an unambiguous 
identifer for the context. Should this be pointed out. Should there be a short 
form, meaning "use the context identifier for this" ? (it would be a mistake to 
force the ctx identifier to be usable as the "content URI")

2. What is the type of the reply ?  Are there constraints on the mime type (it 
should say even (or especially) if this is obvious)

3. ContextManager getContents has various fault replies. Shouldn't the 
specification state exactly which http responses are equivalent.

4. ContextManager has both getContents and putContents. Can a content URI be
used to PUT a replacement contents in the same way (and subject to similar 
security, concurrency considerations if necessary)

5. Is it really desirable to have two ways of doing the same thing ?

6. Are referencing specifications expected/allowed to constrain to use only one 
form ?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.