Re: optimizing container pages serialization to enable streaming

On Nov 15, 2013, at 6:38, "John Arwe" <johnarwe@us.ibm.com<mailto:johnarwe@us.ibm.com>> wrote:

Wow, I time-slice onto something(s actually) else for a couple days and we have real discussions going on!

1: Dumb question, for Eric P I think.  If one is willing to assume an optimized serializer in order to move the proposed ldp:membershipRule "up front", what does the extra level of indirection and the anon  bnode "trick" really give you beyond moving the 3-4 predicates that the anon  bnode would otherwise contain up front?   The mental chasm for me is accepting the notion of an optimized serializer more than whether it's moving a clump of form X vs form Y to a privileged spot.

2: To ErikW's comment, maybe it's fine for prototyping but I'm worried about lifecycle dev costs in product development, and once we create that Thing we own its care & feeding forever.  I would "strongly discourage" my own devs from taking a course like that especially in the general case.

absolutely. forking standard components to tweak them for special cases is a Really Bad Idea. i hope what i wrote did not sound like an endorsement of such an approach. it was meant quite as the opposite.



3: Presenting the option for server implementations seems perfectly appropriate in a companion document; one of the existing ones like BP&G, or another.  As long as it meets the "clients can't depend on it" criteria others laid out, it's a fair investment decision to give server implementers.  I have zero sympathy for it in the mainline spec, where as ErikW pointed out it would add nothing normative; I think it would be a distraction, if anything.

Best Regards, John

Voice US 845-435-9470  BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
Tivoli OSLC Lead - Show me the Scenario