Re: Container Questions

If the spec is silent on something, generally I think the expectation is 
to read those cases as MAY, rather than SHOULD, keeping in mind that 
2119-SHOULD isn't a synonym for MAY as many devs seem to think.
With that translation assumed to be applied to your email, I think all of 
your readings are allowed but not all would be what "most" will do.

> 1.  It seems like an LDP system can create all of the resources 
> POSTed to a container in one operation, and should arbitrarily pick 
> one for the response.

"arbitrary" server choices usually are hard for clients to cope with, 
especially clients that aspire to be general ones.
An LDP-centric server dev might create a container for the set and return 
the container's URL.
A "vanilla RDF store" dev might simply store the entire input graph and 
assign 1 URL, since the presence of multiple distinct subject URIs in an 
RDF graph is perfectly normal.
Which is more logical in any particular case might depend mostly on the 
vocabulary in use and to what degree the server "understands" that 
vocabulary (uses it to affect processing).  A vanilla graph store is not 
going to react to say an OSLC Change Request resource the same way an OSLC 
Change Mgmt server would; even if the LDP-governed portions of the result 
were identical, the side effects will be very different.

> 2.  It is unspecified what happens when the entity-body POSTed to an
> IndirectContainer does not contain the insertedContentRelation 
> predicate, and thus the system can do what it thinks best

Personally I think most would reject it, but I have no objective reason to 
say that.
Not asserting anything != asserting a default, semantically. 
OTOH in certain application domains governed by a higher level interface 
contract layered over top of LDP, that semantic might be part of the 
contract.

> 3.  Systems should support multiple containers with the same 
> membershipResource and the same hasMemberRelation? For example one 
> resource with both direct and indirect containers, both of which 
> contribute to populating the same pool of members in the membership 
> resource. 

I think it's going to very much depend on how much control you have over 
the graph.  If you're trying to use LDP as a way to get consistent 
interfaces draped over existing graphs that you can't just change 
incompatibly, then you might very well end up doing what you describe.  If 
you're doing something new from scratch, "who needs anything more than a 
Basic Container??" has been the loud oft-repeated refrain from several in 
the wg.

I can see both sides; but coming from my background, I suspect that even 
the currently-new Basic-only ones will eventually become "legacy" data (if 
they're successful; and if not, "who cares") so many will end up doing 
what you describe over time.  Reality is messy, inconvenient, and annoying 
sometimes^W most times, but to paraphrase Woody Allen it's still the only 
place you can get a good steak.


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead