[oslc-core] Issue-43 drafts

[Steve K Speicher]

John,
Thanks for doing this, much easier for me to parse out the issues and 
proposed resolutions. 

43-1: +1
43-3: +1
43-4: +1
43-5: -1 (see below)

Point 1:
Proposed changed for "Occurs":
  "The *–many values SHOULD NOT be interpreted as a requirement that 
providers or clients must will be able to accept an unrestricted quantity. 
 Providers and clients MAY impose implementation-specific limits on what 
they will accept."

Not to open another issue but I wonder if it would be best to include a 
separate description for each valid value of Occurs.

Point 2:
For end of page 2, paragraph says:
"Note: For enumeration URI values above, e.g. XSD Boolean ( 
http://www.w3.org/2001/XMLSchema#boolean, reference: XSD Datatypes), the 
cited reference defines any relevant semantics. Those URIs lacking an 
explicit citation are self- defining, i.e. retrieving the enumeration URI 
itself results in a vocabulary document being returned."

What does this have to do with the stated issue in the document about 
Occurs?

43-7: +1
43-8+9: -1 (see below)

I find this wording a bit hard to know what I should do, especially if 
today is really yesterday.
"...suggesting which classes implementations should expect to find given 
what is known today"
I'd propose:
"...suggesting which classes implementations should expect"

As I commented in the attachment on the statement:
"Providers and clients are strongly RECOMMENDED to support all “expected” 
classes listed in a property’s description. "
This statement may make sense for providers but I'm not sure this makes 
sense for clients.  I'd propose this alternate wording:
"Providers and clients are strongly RECOMMENDED to support all “expected” 
classes listed in a property’s description and clients SHOULD be flexible 
enough to handle unexpected classes. "


Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 05/29/2012 06:10 PM
> Subject: [oslc-core] Issue-43 drafts
> Sent by: oslc-core-bounces at open-services.net
> 
> Issue 43 [1,2] has proven interesting, as last week's salvo of 
discussion-
> generators may have telegraphed. 
> Although I was initially reluctant to split this up into pieces, it 
became 
> obvious upon first preview to another human that it's the right thing to 
do. 
> 
> Some drafts for sub-issues that I believe to be likely small and non-
> controversial (so we could potentially shoot through them on tomorrow's 
call). 
> 
> 
> Some drafts for sub-issues that are slightly larger in scope, 
potentially 
> more controversial (agenda fodder, time permitting): 
> 
> 
> 
> These represent over half of the known issues I've found in the course 
of 
> drafting -43, so would not be bad to get them under our collective belt, 

> time permitting. 
> 
> 
> [1] http://open-services.net/pipermail/oslc-core_open-services.net/2012-
> April/001288.html 
> [2] http://open-services.net/bin/view/Main/OslcCoreV2Issues 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario [attachment "20120530 Draft for 
Core
> Issue 43-1.pdf" deleted by Steve K Speicher/Raleigh/IBM] [attachment 
> "20120530 Draft for Core Issue 43-3.pdf" deleted by Steve K Speicher/
> Raleigh/IBM] [attachment "20120530 Draft for Core Issue 43-4.pdf" 
deleted by
> Steve K Speicher/Raleigh/IBM] [attachment "20120530 Draft for Core Issue 

> 43-7.pdf" deleted by Steve K Speicher/Raleigh/IBM] [attachment "20120530 

> Draft for Core Issue 43-5.pdf" deleted by Steve K Speicher/Raleigh/IBM] 
> [attachment "20120530 Draft for Core Issue 43-8+9.pdf" deleted by Steve 
K 
> Speicher/Raleigh/IBM] _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120530/6b8c1b5c/attachment-0003.html>