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@IBMUS > To: [email protected], > Date: 05/29/2012 06:10 PM > Subject: [oslc-core] Issue-43 drafts > Sent by: [email protected] > > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
