[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: <none>
Scott, Thanks for the excellent feedback. This was fairly thought provoking so it took some time to respond. Most of the suggestions will be addressed in v0.5. See my comments in line. "Nieman, Scott" wrote: Feedback on v0.4 ================ I may have stated some of these comments before. General: We must change the verbiage to reflect ISO 11179. Registrant is Submitting Organization (SO for short), and Registrar is Registration Authority (RA for short). I would like to propose a compromise here. What if we changed verbiage to the ISO 11179 terminology but kept the interface names unchanged. I will run a draft v 0.5 change by you and see if it meets your intended suggestion. Line 20: correct to spell Nieman Sorry Scott. I fixed in one place but did not in another. line 142-147: Services. I do not believe that Discovery is even necessary to spell out, as that is based on a classification scheme. Part 1 I am not sure about this. Discovery as a service is the end. Classification is a means to that end. Retained for now. specificatioin suggests these services are within the Registry Service; Transformation Service, Workflow Service, and Quality Assurance Service. I am not sure what these do. Need to get educated on each of these. Can you write a short note describing these at you convenience (not needed for Tokyo). I have included them for now. Line 148-153: I am not certain if the title is clear. Are these are "goals" of this specification could actually speak to the fact that we are trying to "communicate functionality of a registry service to software developers". Good idea. Added. Line 163-165: "bootstraps the communication" is unclear. It seems this is a mix of authentication and company registration in general. They represent separate functionality to me. I have only focused on registration assuming authentication will be based on ebXML TRP and the TPA between registry and registry client. Line 166-169: We debate the word "document" before at an early meeting. The word that was agreed upon in Belgium was "object", since an object can be collection of other objects, and these objects can be interrelated. Each object can be separately classified and/or classified as a collection. Interrelationships between objects are critical, as this will enable tpaML. Line 169: Add "XMI" and "software components compliant to a registered business process" to the list. software components are critical to aiding emerging countries (a key United Nations interest), and supports an open source philosophy. e.g., if companyA needs to do business with companyB, and companyB supports a registered business process, the companyA may be able to download software (such as a plugin) that enables communicate within the specified business process. Therefore, the term "document" is not general enough and object is more realistic. Good point. This will be a major change in v0.5, where DocumentManager will be replaced with ObjectManager, managed documents with managed objects etc. Let me know if my interpretation is correct and that the proposed changes will address the issue you raised. Line 188-189: Not showing the methods may save space, but some readers may prefer a full UML class diagram. suggest putting the full model in an appendix, and referencing here. Will do. Line 216-245: I suggest using the UML based use cases in Part 1 or elaborated upon in Part 2 draft (in archives). Section 2.3.2 through 2.3.4. seem be the same use case. they are the "submit object" and "create object" use cases in Part 2 draft. Line 274-277: I am unconvinced that multiple arguments imply multiple payload. It is possible to implement an argument as a complex "string" which is in fact an XML document itself. We delivered a marketplace trading system last October that utilized this concept and made our lives simply. The root tag (after stripping off the TRP stuff) pointed to the java member function, and we passed the entire XML document as a string to the member function argument. It is not necessary to state this here. It seems to imply SOAP, and thats my personal gripe about SOAP and Web Services in general; probably because we deliver a system before the specification v1.0 was even published. My objective with the diagrams was to have a direct mapping between diagram and the TRP messaging interface, thus allowing the diagram to pictorially describe the interface based on TRP messaging interface. The arguments to the methods map to TRP messages. I do not see a need for change here. Lets talk more if you disagree. Line 387-399: I do not agree this list should be limited. It is applicable to any type of object that needs to be registered. However, this list is OK as a minimum for B2B I think we are saying the same thing. The list is a start and will grow. No change planned. . Line 401-403: Perhaps we should add "versioned" to state diagram, however, one could imply that in "Created" I guess. Initial version is better termed Created IMHO. BTW I did plan to add version support with checkin/checkout in future revs (post Tokyo). Line 411: Classification should be Classification Scheme, and this should be a valid XML document. Each classification scheme is a unique hierarchical view of the attributes of the submitted object. A business process is different than an tpa is different than a data interchange DTD or Schema. I believe we need to have a clear understand of this and not create a string like approach. This will imply a set of operations that include assignClassificationScheme, nextNode, previousNode. A classification scheme is CRITICAL for query services. I agree. We will work out the details next week. Can you provide some examples? Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC