Martin, I agree with the point you are making about how we are managing the inclusion of features. I think we should re-examine the current process, which is very lightweight. It has resulted in rapid progress, but going forward we should have more structure. Ideally, we should use a requirements tracking mechanism where new requirements are proposed, discussed, and triaged. Any new feature should be traceable back to an approved requirement. Each feature should also be tracked so that the discussion and design alternatives can be reviewed at later date. One could argue that this information already exists in the wiki and mail archives, but in practice it's very difficult to reconstruct the decision process from those sources.
Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally/Raleigh/IBM@IBMUS To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 12/16/2010 09:56 AM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 I don't think we should remove it, since it's already there, but I think that in the future we should require a higher level of proof of both the need and the value of a proposed solution before including things in the spec. Adding more options to specs reduces the value of the spec and increases the cost of adoption - the barrier for entry of new features should be very high. To be honest, I think the core spec has too much. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 From: Arthur Ryman/Toronto/IBM@IBMCA To: Martin Nally/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 12/15/2010 04:00 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 Martin, I used iPhone as an extreme case. I've seen many performance problems caused by services returning too much data to browser and desktop clients. When you examine these problems, they are usually caused by users using a product in ways that the dev team did not expect or test. Some general mechanism that allows clients to limit the amount of data returned seems to be very well motivated by actual experience. Paging is a standard solution to avoid sending all the data at once. Either we allow the client to advertise its limits, or we require the server to infer the limits based on other information such as the User-Agent. Are you proposing an alternative to the current design, or just that it be dropped? Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally/Raleigh/IBM@IBMUS To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 12/14/2010 07:27 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 I think the time to consider this would be when we had real experience from iPhone implementers suffering a problem, and a prototype showing that this is the simplest effective solution. It might seem like a good idea to anticipate solutions to "obvious" potential problems, but my experience is that this does not lead to good outcomes. Our ability to anticipate what the problems will really be and imagine likely solutions is much less than we think, and this sort of thinking leads to bloat and wasted effort on problems that turn out not to matter, or solutions that don't work. This sort of anticipation is what lean, Kanban and other popular methods tell you not to do. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 From: Arthur Ryman/Toronto/IBM@IBMCA To: Martin Nally/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 12/14/2010 06:35 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 Martin, "?oslc:pagesize=n" is useful for clients that have limited bandwidth or processing ability. In practice, the size requested by a client is much smaller than what the server could generate. For example, an iPhone might request just 10 items per page whereas headless clients, such as ETLs or crawlers, might request 1000 items per page. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally/Raleigh/IBM@IBMUS To: Arthur Ryman <[email protected]> Cc: [email protected], [email protected] Date: 12/10/2010 11:36 AM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 Yes, makes sense. See a separate note where I asked why we have "?oslc:pagesize=n". That is the only place I know where there is any suggestion that pages might be equal-sized. I'd be happy to get rid of that. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 From: Arthur Ryman <[email protected]> To: Martin Nally/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 12/10/2010 10:20 AM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 Martin, The point that was bothering me was that it might be a burden on implementations to require that the number of pages and the RDF triples in each page are the same for all representations. For example, suppose an implementation imposes a limit of 1 MB per page. Suppose in Turtle you can pack 10,000 triples per MB, but in HTML you can only pack 1,000 triples per MB. Suppose a resource has 2,000 triples. The server could return then all in 1 page of Turtle, but would require 2 pages of HTML. I am suggesting we allow that. Does that fit with your view? Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally <[email protected]> To: [email protected] Cc: [email protected], [email protected] Date: 12/09/2010 03:30 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23 Sent by: [email protected] I agree with what you wrote, but it doesn't seem to contradict what I said. There is something slightly comic about this conversation. I think you provided a very clever insight that both simplifies and generalizes the concept of paging, and now you seem to be arguing against your own clever idea. I was worried that it was conceptually difficult to define what it means to return the first half (or third, or quarter) of an HTML representation. Your insight is that you do not have to worry about that - you can define pagination in terms of the underlying RDF resource. There are some minor complexities in "paginating" an RDF resource that has blank nodes - all triples that reference the same blank node need to appear on the same "page" - but otherwise paginating an RDF resource is conceptually trivial. Representing those pages is now well defined - all you need is a valid HTML, JSON, RDF/XML, Turtle or other representation of the page, which is itsefl a well-defined RDF resource. No special specification or documentation is required. It's a very simple, elegant model - go to the top of the class. A server that is paginating a resource for HTML representation is free to define the pages in a way that is convenient for HTML display, as you point out below. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 > > Martin, > > Although any resource may have multiple representations, some resources > may only have one representation. In the case of paging, I think it makes > sense to allow the page contents and breaks to depend on the > representation initially selected. Different representations will differ > in their compactness, e.g. one page of Turtle might take 10 pages of HTML. > > Regards, > ___________________________________________________________________________ > > Arthur Ryman, PhD, DE > > Chief Architect, Project and Portfolio Management > IBM Software, Rational > Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 > _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
