Re: solution modifiers & construct/describe

On Mon, Jun 27, 2005 at 04:57:01PM +0100, Seaborne, Andy wrote:
> True it's example driven but that can't mean there is an example for every 
> possible usage pattern.   That would be a whole book.

I think you can safely assume I understand *that*! The point is that here's
an instance where the doc is unclear and an example would help clear up the
confusion. Adding another example *never* implies adding all conceivable
examples, after all. :>

> then the definitions use "SM(QS)" to show the application of the modifiers.
> 
> Err - CONSTRUCt doesn't clearly - that needs to be corrected.

Yep, precisely.

> I'd like to make it more permanent (it is currentl broken due to CSS 
> chnages :-() and then a link in the doc could be made.  An alternatively, 
> can we provide a static page of the definitons and reference that?

I'd prefer to see an appendix with all the definitions together *inside* the
spec. (Actually, I'd prefer to see all the defintions rewritten to use
relational algebra, but that's an idle preference at this point! :>)

> Err - that woudl make the defintions long, repetitive (obscuring the new 
> salient part) and likely inconsistent as changes are made.

I obviously don't agree, but, as I said, that's an alternative possibility
to my preference that defintions be gathered into an appendix inside the doc.

> it is not a partcularly important one for describe/construct as the 
> returned graph is limited in ways that the requestor can't necessarily 
> determine (limit/offset and ordering are a poor cursor mechanism). 

I agree. So why don't we just drop this? Disallow those solution modifiers
for DESCRIBE & CONSTRUCT query forms. Seems a perfectly reasonable
restriction.

> In the 
> case of construct or describe I think the use is more to do with error 
> control than slicing graphs.

I don't find it useful at all, and I'd like to see it just dropped. That
would solve a lot of these problems. As I recall both the discussions, the
use cases, and the requirements, these SMs were always about variable
binding results.

Kendall

Received on Monday, 27 June 2005 16:26:00 UTC