Re: Issue-80: Post media types usable for Create; background for proposal

> "Wilde, Erik" <Erik.Wilde@emc.com> wrote on 06/07/2013 07:07:58 PM

Look Henry, your wish is my command ;-)


> - another way ... introduce the concept of "link hints", currently 
proposed (but not yet

Thanks for the reminder Erik, it has been several months since I skimmed 
json-home.  Valid additional source of inspiration.

FWIW, I did consider an Accept-Post (no -Create) on paper, but I rejected 
it on two major bases: (1) does not solve the whole problem... if I don't 
know the semantic, knowing what media types POST accepts is just loading 
the gun already pointed at my foot (2) the "POST for Create" semantic did 
seem to be a pattern widely re-usable(ed) enough that I was willing to 
risk one step in the direction of the "pushing to the extreme" 
Allow-Post-MyPrivateSOAPyOOMethodName since the community provides a check 
on abuse.

"hints" are of dubious value to implementations.  If you act like you 
believe them and don't verify, then you're not treating it as a hint.  If 
you verify, why did you need the hint... the gratuitous variability 
argument I hear people raise on these matters.


> - link hints are in the representation, so when you have something akin 
to
> AtomPub's service document, you can potentially link to various POSTable

Exactly - I was not attempting to invent an LDP service document this late 
in the game (vs Last Call schedule).  The WG could decide to do so.
Bad me for not rendering that implicit decision explicit.


> point out that Accept-Patch really only talks about the HTTP 
interactions,
> without trying to go any further. in my mind, that's a cleaner way to go

It has that luxury because the semantics of Patch are constrained in a way 
that does not apply to Post.
If the LDP WG is comfortable with an incomplete solution (historically 
"not"), Allow-Post (w/o -Create) would be a reasonable step.  Anticipating 
the historical reaction, I chose "with -Create" to spark exactly this 
discussion.


> personally, i'd rather handle this in the vocabulary than in a header.
> also, i think it would be great to handle this generically (a la link
> hints) and thus allow other hints to be used as well, without having to
> change the vocabulary. but that may be a bit ambitious at this point in

I see two alternatives that would line up with this idea, so please add 
more if you have them in mind.  (a) add to Container ... overloading it 
perhaps with 'service document' functions, (b) adopting something like 
json-home wholesale (c) return 'service doc' triples along with container 
representations, optionally(?).  Downsides I see, just off the cuff:

(a.1) 'hints' are then vocabulary specific - cannot use json-home's even, 
since json-home's hints have no namespace and containers are RDF which 
assumes URIs identify things.
(a.2) Since the HTTP URL may give back triples on multiple RDF resources, 
with no required relationship between the HTTP request-URI and *any* of 
the returned subject URIs, the various assertions from the 
possibly-multiple containers might conflict.  (Thinking through these 
cases is the more general 'problem' I mentioned in passing on today's 
call.)

(b.1) Not yet standardized, as you said.
(b.2) The mixing of "no namespace and RDF" would likely generate a new 
round of teeth-gnashing and "tens" of emails ;-)
(b.3) Adopting more than one required media type in LDP, ditto.

(c.1) Work needed to define its content.
(c.2) To what degree can we re-use link hints of the json-home sort, if 
it's an RDF model; will people agree to something not-RDF (ala b).

There might be some room to finesse this by defining a "hint" predicate 
whose object is a string from 'the' (ha! 'this') hints registry... not 
sure what people think about doing so.  <whine> If IETF would put a 
namespace on them, it would be far easier to play nice with linked data. 
But it's going in the opposite direction over time; ns was dropped from 
link relations with 5988, modulo the ones grand-fathered from Atom. 
</whine>

Do you have any sense for how fast json-home is likely to proceed to 
standard, relative to the LDP schedule in the charter?


> "Wilde, Erik" <Erik.Wilde@emc.com> wrote on 06/07/2013 06:55:25 PM:

> - if the accepted media types of POST are fix, ...
> .... but i think in this case, they are not fix;
> each LDP server can decide to accept different media types.

Correct, as things stand today.

Rest I think were covered by your later-in-time email already.



Best Regards, John

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