OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: <none>


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

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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC