ebXML Working Draft May 12, 2000

ebXML Registry Reference Specification: Business Domain

ebXML Working Draft Issue Date May 12, 2000

First Comment Review Disposition

Issue first Draft	May 15, 2000
Close of 1^st comment period	May 29, 2000
Submit revision and disposition for 2^nd commend period	July 29 , 2000
Close of 2^nd comment period	Aug 7, 2000
Submit final revision with comments and disposition	Aug 11, 2000

Comment number	Submitter name	Date submitter	Start line	End Line	Description of comment or cut and paste section	Resolution of comment
1	Jarry Eric	05/17/2000			General comments about word format.	Changed figure numbering to be automatic
2.1	Mary Kay Blantz	5/18/2000	43	51	Indent for readability	Changed
2.2	Mary Kay Blantz	5/18/2000	53	58	Indent for readability	Changed
2.3	Mary Kay Blantz	5/18/2000	60	65	Indent for readability	Changed
2.4	Mary Kay Blantz	5/18/2000	66	68	Indent even further for readability	Changed
2.5	Mary Kay Blantz	5/18/2000	69	69	Indent for readability	Changed
2.6	Mary Kay Blantz	5/18/2000	70	70	Indent even further for readability	Changed
2.7	Mary Kay Blantz	5/18/2000	105	105	Change "interfaces" to "interface"	Changed
2.8	Mary Kay Blantz	5/18/2000	123	125	Include the survey or statistical results and which users, associations, consortia, and standards organizations that prove the mentioned distrust.	Removed the comment about survey etc…
2.9	Mary Kay Blantz	5/18/2000	145	145	Start the sentence with "The ebXML…"	Changed
2.10	Mary Kay Blantz	5/18/2000	152	152	Change "as according to" to " in accordance with"	Changed
2.11	Mary Kay Blantz	5/18/2000	183	183	Remove the first "other"	Changed
2.12	Mary Kay Blantz	5/18/2000	219	219	Put "the" between "in" and "past"	Changed
2.13	Mary Kay Blantz	5/18/2000	231	231	Unless the word "purchase" has some special meaning in this context, I'm not sure why we are including this. Perhaps change the word "purchase" to "obtain" which may or may not imply some financial transaction.	Changed
2.14	Mary Kay Blantz	5/18/2000	237	237	Change "Common Business Object" to "Core Component"	The group doesn’t agree with this change and will revisit this suggestion.
2.15	Mary Kay Blantz	5/18/2000	243	243	Change "each semantic unit" to "one or more semantic units"	Changed
2.16	Mary Kay Blantz	5/18/2000	266	266	Is "knows" valid in this context? Maybe "is programmed to" instead?	Changed the word to “can”
2.17	Mary Kay Blantz	5/18/2000	268	268	Must the developer be a "team", or is an individual possible?	Didn’t change since a team can be a team of one
2.18	Mary Kay Blantz	5/18/2000	290	293	Domain Use Case provides an overall, high-level context of the business problem, a boundary to the scope of the functionality, and traceability to the actors involved as defined in the Actor Relationships hierarchical diagram. It does not delve into how the system performs the tasks on a functional basis.	Changed to the sentence suggested by Mary Kay
2.19	Mary Kay Blantz	5/18/2000	316	316	Add "schemas" to the list.	Changed
2.20	Mary Kay Blantz	5/18/2000	324	325	Must the RA communicate with the SO if changing the submission? I say yes. And the rules to do so must be documented somewhere.	The rules will be defined in Part 2 Document
2.21	Mary Kay Blantz	5/18/2000	348	351	The sentence needs work, but I can't fix it.	Changed to the following: The ISV is a special type of Corporation that can, through its association to the SO, register and submit software components that have been constructed, tested, and certified to be compliatnt to the retrieved specification(s). The components will then be available for download by the Business User.
2.22	Mary Kay Blantz	5/18/2000	354	354	The use of "good" implies that "bad" specifications may be found in the R & R's.	Removed the word “good”
2.23	Mary Kay Blantz	5/18/2000	383	383	An example of a reason for an ebXML-compliant Business Application to interact with an ebXML Registry.	Changed
2.24	Mary Kay Blantz	5/18/2000	400	400	and/or 2)	Changed
2.25	Mary Kay Blantz	5/18/2000	403	404	Remove this sentence. Any actor anywhere might charge for anything.	Changed
2.26	Mary Kay Blantz	5/18/2000	409	409	Change "cases" to "case"	Changed
2.27	Mary Kay Blantz	5/18/2000	417	417	Line 414 says optional, but 417 says optional or mandatory. Are these in conflict?	Changed word from “These” to “The”
2.28	Mary Kay Blantz	5/18/2000	452	453	Change "common business objects (Core Components)" to Core Components	The group doesn’t agree with this change and will revist this suggestion
2.29	Mary Kay Blantz	5/18/2000	494	495	The sentence needs something. Maybe just remove "what" in line 495	Changed
2.30	Mary Kay Blantz	5/18/2000	501	505	If TRP in line 505 is Transport, Routing and Packaging, then line 501-502 needs to have Transport, Routing and Packaging instead of Transport, Package, and Routing.	Changed
3.1	Gait Boxman	5/18/2000	145	149	There is no point in referring to W3C separately. ISO, IETF and others are equally important. Yes Xlink and Xpointer are key specs. So are ISO11179, TCP/IP, DSN, HTTP, SMTP and others. Proposed change: either remove text, or change to something like: In the design and implementation, the ebXML Registry and Repository project team will consider any existing or appearing standards from accredited standards bodies that it finds of value to the project.	Modify sentence to include part of the proposed change
3.2	Gait Boxman	5/18/2000	125	153	I believe we are highly dependent on ISO11179. It should be referenced here. Proposed change: Add a short description of ISO11179 and how we depend on it. Something along the lines of: ISO specification 11179 defines a general model for registries and repositories and the roles and responsible parties with respect to those systems. This ISO specification has been used as a starting point for the ebXML Registry and Repository specifications. EbXML compliant registries and repositories are also compliant with ISO 11179 rulings.	Added the first two sentences proposed by line 125.
3.3	Gait Boxman	5/18/2000	151	153	This is orthogonal to the project itself. Whether we print the model on paper, include it in a Word (or PDF) document or PowerPoint presentation, display it with Rose, or generate an XMI representation has no significance to the model or the project itself. Proposed change: remove text.
3.4	Gait Boxman	5/18/2000	154	162	Mixing glossaries and terminologies from four different half-related sources is bound to cause problems with multiple definitions and uses. We need a way to resolve that problem. I can see two options: we either set a prevalence order on the sources, or do build our own glossary. Proposed change: Either augment the text with: When terms are defined in more than one of those documents, the document that appears first in the above list will prevail. Or change line 162 to: The ebXML Registry and Repository project team will create it’s own glossary which will be merged into the overall ebXML glossary.	Changed to add proposed line of text for line 162
3.5	Gait Boxman	5/18/2000	163	404	As argued earlier in the Brussels meeting, I have serious problems with the number of different actors and the roles they play against the registry and repository. Due to the extensive text, I’m not going to propose a complete new text. However, I would like to see that the actor relationship diagram and use case diagram are restricted to actors, which play a role at the system boundary and use cases within the system. Proposed change: The best guideline here would be the business domain use case at line 300, with the following modifications:	Comments divided by issues
3.5.1	Gait Boxman	5/18/2000			Remove ‘Create Map between Specifications’ and ‘Develop Software Components’. These are not use cases/activities within the registry and repository system, but activities for parties external to the repository. These parties might use the repository to retrieve and/or submit items through the appropriate use cases. (Of course, this also removes the related actors from the diagram, unless you want to link them to Retrieve Items, in which case they will be removed in the next step.) Having done this, ensure that for every use case, there is only one actor who starts that use case, and name the actor appropriately. This ensures that we have a proper logical model of the system. More specifically, apply the following changes:	For Debate: The intent for these use cases was to illustrate a tighter coupling of application development tools, including mapping tools, to the repository. There are likely addition interface operations that would invoke check-out/check-in and versioning capabilities of the repository. There is no rule in UML that only actor can instantiate a use case. In fact, is in commonly expressed in the UML Users Guide and provides an effectively technique to discover new requirements based on the viewpoints of all actors.
3.5.2	Gait Boxman	5/18/2000			Remove ‘Registration Authority’ as an instantiating actor for ‘Register Company’ and ‘Classify Submissions’, as the ‘Submitting Organization’ already is the instantiating actor. You could leave the link as a related actor.	For debate: Viewpoint/ use case style issue
3.5.3	Gait Boxman	5/18/2000			Remove all links between actors and ‘Retrieve Items’, except for ‘Guest User’, as they all play the same role. If needed, ‘Registration Authority’ could be linked as a related actor (e.g. for logging purposes).	Maybe; the ebXML Business Application should remain as it produced/ instantiated by the Independent Software Vendor, and not part of the inheritance hierarchy.
3.5.4	Gait Boxman	5/18/2000			The link between “Registration Authority” and “Store Items’ is also strange. In my view you can only store items that are properly submitted. Even if the RA does it on it’s own, it plays the role of an SO, through the ‘Submit Items’ use case.	This is a viewpoint issue. The RA grants public access to the submitted items. This may not be an automatic process to submit an item and let the world be instantly aware of its availability.
3.5.5	Gait Boxman	5/18/2000			Next are some proposed renaming exercises: Rename ‘Register Company’ to ‘Register Submitting Organization’, an SO does not need to be a company. It could be a private person, non-profit or governmental organization.	OK
3.5.6	Gait Boxman	5/18/2000			Rename ‘Guest User’ to ‘Information Consumer’ or ‘Ordinary User’. It is really the ordinary user who retrieves information for the repository.	Disagree, but we understand your concern. This was debated in Brussels and the group felt the name, as awkward it sounds, is common from an administrative point of view.
3.6	Gait Boxman	5/18/2000	326	338	Note that in the ebXML Requirements document, which was approved in Brussels, it is stated that ebXML compliant registries and repositories have open and perpetually free access. In my mind, this precludes the need to authenticate for read access with either system, nor a trust requirement between a registry and repository. Proposed change: remove lines 335-338	Disagree, RA may impose a authentication requirement.
4.1	Bob Miller	5/23/2000	99	99	Labels inside chart overlap schedule bars, reducing readability	This graph is from UN/CEFACT and will be communicated to UN/CEFACT the comments on readability
4.2	Bob Miller	5/23/2000	168	169	Text in these diagrams range from unreadable to acceptable. Ideally, the font size would be consistent across all diagrams, and would be the font size used in the document proper.	Okay Font will be increased.
4.3	Bob Miller	5/23/2000	154	162	All terms and definitions, regardless of their source, should (and are intended to appear in an ebXML Glossary, which should be referenced in this section.	Changed
4.4	Bob Miller	5/23/2000	246	247	Change ‘and / or’ to ‘and of the’	Changed
4.5	Bob Miller	5/23/2000	300	325	The diagrams and text suggest that items may only be stored into a Repository via the Registry. The submitting organization should have the option of storing data in the Repository prior to Registry, and then instructing the Registry to reference the stored data in the Repository, rather than creating a new Repository copy of the data.	The UML model use cases don’t implied whether it is physically registered in the registry from the repository or SO.
4.6	Bob Miller	5/23/2000	312	312	I am concerned here with the use of the word ‘package’. IMO, what is being submitted is an object (represented as a stream of bits/bytes). This object could contain other objects which also are to be Registered. I propose the text be changed to: 1) Change ‘Submit Items’ use case to ‘Submit Object’ Use case wherever it appears. 2) Change 312-318 to: The Submit Object use case provides the ability to submit an object to the Registry. The use case may request storage of the Object in a Repository to which the Registry has ‘write authorization’, or may request that the Registry reference the object as previously stored in a Repository. A record of the object is created in the ebXML Registry (hence the term “register”). Imbedded objects within the submitted object may also be registered in the Registry, at the discretion of the SO. (For example, if the submitted object is an XML DTD, the SO may also request registration of each XML Element defined within the DTD.) The RA … NOTE: Throughout the document, each use of the word ‘package’ and the word ‘item’ should be reviewed to see if ‘object’ is more definitive.	Will be discussed more on the list-server
4.7	Bob Miller	5/23/2000	361	361	Change ‘the ebXML Registry’ to ‘an ebXML Registry’ Change ‘an ebXML Repository’ to ‘has “create” access to at least one Repository.’	Changed
4.8	Bob Miller	5/23/2000	362	363	‘a complete background check’? Suggest: The RA may authorize or reject the SO’s registration request that was initiated in the Register Company use case. Which action is taken by the RA is beyond the scope of the ebXML specification.	Changed
4.9	Bob Miller	5/23/2000	366	371	Surely the SO should have some say in whether public access to the submitted object is to be granted. An SO may wish for example to provide public access to a digest of the submission, but retain control over access to the object itself.	What is the proposed change?
4.10	Bob Miller	5/23/2000	414	416	There cannot be additional services within the ‘Registry’ <<Service>> package that may be performed by the Repository. The services of the Repository must be fully defined by the Repository, though of course some such services may be optional. Furthermore, I cannot think of an optional Registry service that requires a Repository service not already required by the basic Registry service. I would drop this paragraph, but I may simply not understand what the author is trying to convey, given the emphasis placed on ‘important’.	Changed the paragraph to explain better the meaning.
4.11	Bob Miller	5/23/2000	440	440	I would drop ‘and store them in the Repository’, as earlier text in this document already attributes the ability to store them in the Repository to the Registry services. As currently worded one might read that the SO must perform two independent operations (and I would suggest in improper order).	Changed
4.12	Bob Miller	5/23/2000	570	571	The relationships among ‘Work in Progress package’ (e.g., line 448) and ‘Workflow Service’ and ‘Library Control System’ are not clear in 405-466. Also, is there a relationship between workflow service and library control service?	This is implied by the dependencies between the work in progress and registry as well as the repository to the registry.
4.13	Bob Miller	5/23/2000	495	495	Delete ‘what’	Changed
4.14	Bob Miller	5/23/2000	503	505	‘the ebXML Registry and Repository is’ suggests one inseparable service, whereas the Repository is an independent service. Suggest: Since the ebXML Registry and Repository are also ebXML-compliant Business Appllications, communication with these services relies upon the ebXML TRP messaging services.	Changed
5.1	Melanie McCarthy	5/23/2000	73	89	After reading the various sections that are being brought forward, I am concerned that the specific information that I believe that ebXML has promised to deliver is not being included. Specifically, my expectation was to see published a recommended architecture model for a repository to be ebXML compliant.	We have three more specifications to produce that will cover this in detail.
5.2	Melanie McCarthy	5/23/2000	166	167	If this is a web of Registries & Repositories, I would expect that various security models would be recommended – not to allow for the security policy to be at the discretion of the registration authority.	Security will be expanded in detail in part 3 and 4 specifications.
5.3	Melanie McCarthy	5/23/2000	173	174	It appears that the “guest user” must act on behalf of an organization. Can he not also represent an individual?	The Arrow is a UML inheritance association.
5.4	Melanie McCarthy	5/23/2000	190	190	I don’t understand the purpose of the Business User that identifies him as different from the Business Domain Expert.	Changed and remove Business user
5.5	Melanie McCarthy	5/23/2000	216	218	The Business Process Analyst should not ‘challenge’ the Business Domain Expert, rather he could provide constructive recommendations regarding alternative methodologies. But ultimately he should not be in a position to override the need of the Business Domain Expert. Alternatively, if this concept is pursued, there should be an appeal process where the Business Domain Expert’s point of view can be appealed.	Changed paragraph
5.6	Melanie McCarthy	5/23/2000	322	324	Again there should be an appeal process, if the SO believes that the Registration Authority has acted erroneously and re-classified information, there should be a process to appeal the decision.	This will be defined in Part 2 specifications
5.7	Melanie McCarthy	5/23/2000	353	356	Information that may be stored in the repository may be very confidential, potentially providing a competitive solution. Thus it should not be accessible by the ISV.	Disagree since the RA and SO can control access rights
5.8	Melanie McCarthy	5/23/2000	363	363	Is there a time frame in which the SO must complete the background check?	Changed
5.9	Melanie McCarthy	5/23/2000	366	366	Is only information that is ‘public access’ allowed in the repository?	No what is the proposed change?
5.10	Melanie McCarthy	5/23/2000	476	478	As more information is cached in memory, is there a concern regarding responsiveness of the registry?	No what is the proposed change?
6.1	Jacques Littre	5/25/2000	168	264	1 - Figure 2 - line 168 & section 2.4 line 255 to 264 The figure 2 as well as the section 4 is not clear about what a "Industry Consortium" is exactly in regards to the "corporation" actor whilst it seems natural that there is a clear link between Industry Consortium and Corporation (there is no Consortium possible without corporation members). So, we propose therefore to add in the figure 2 an UML aggregation relationship between the Industry Consortium actor and the Corporation actor. On the aggregate side, the multiplicity should be [0..N] whilst on the Corporation side, the multiplicity should be [2..N]. An second aggregation relationship should also be reflexive on the Industry Consortium itself (since a consortium may have consortia members) with a [0..N] multiplicity adornament. This solution also illustrates the fact that a Corporation may act (as Registration Authority) on behalf of a consortium (which is very often the case anyway).	Changed
6.2	Jacques Littre	5/25/2000	175	260	This should also impact figure 3 (line 175) and figure 7 (line 260) which should show those aggregations.	Changed
6.3	Jacques Littre	5/25/2000	259	259	Section 2.4 (line 259) should also contain a new paragraph explaining that "The industry consortium is made of corporations and/or other industry consortia". And that " Standardization organizations are considered as an Industry Consortium too". (Otherwise they probably should appear as a new actor in the figure 2 as subclass of Registration Authority).	Changed
6.4	Jacques Littre	5/25/2000	168	168	Still on figure 2 (all actors) Shouldn't we align the Actors and roles illustrated in this figure with those defined in the Eco framework ? Why do we diverge from Eco on this ?	The group doesn’t agree on this and we should revisit.
7.1	Martin Bryan	6/06/200	234	238	If the Technical Assessment actor is supposed to "identify semantic overlap" it is important that this actor is well versed in the application of the techniques developed by the Core Components team to remove semantic overlap within core components. He should also be aware of how overlap will affect core components, and the procedures used for reviewing core components.	Correct. No change. We called the Core Component output common business objects. We also understand there isn’t an agreement whether a Core Component is a Common Business Object, however, this is the main intent as you state.
7.2	Martin Bryan	6/06/200	273	282	The role of Software Agents in the business process is likely to be difficult to specify. What is important is that the repositories and registries team define APIs that can be used by software agents, and means of distinguishing when a request comes from an agent and when it comes directly from a Guest user. (Indirected requests should normally be given lower priority as they are asynchronous.)	Yes. No change. It is agreed that the agents requests be tracked versus that of other requests. That is why we included it as a separate actor. Others still feel that these actors could be consolidated and you are validating our initial thoughts.
7.3	Martin Bryan	6/06/200	307	320	The process by which Submitted Items may be approved by Submitting Organizations needs to be clarified by reference to lines 367/369.	We added “…by the RA (see.3.4)” on line 307.
7.4	Martin Bryan	6/06/200	336	337	How can a guest user be "authenticated to the Registry".?	Authentication is part of the security service. The Registry service will receive requests only if the session is granted by the security service. Some systems require simple authentication to track who has visited a site. The RA is responsible for defining the rules. The following change was made: Line 336: Through the use of the Security Services and dependent on the access rights defined by the RA, the Guest User …”
7.5	Martin Bryan	6/06/200	386	388	These lines (except for the first word of Line 386) are not appropriate in an ebXML specification.	Sentence deleted.
7.6	Martin Bryan	6/06/200	430	465	Technical Specifications should follow Work in Progress rather than precede it. Rationale: Work in progress is by definition something you do not want the public to see. At the point you want to make it visible then you declare it as a Technical Specification, and make it accessible to people browsing the registry. Only when a public comment period has passed should it become a Submission that can then be approved as a registered object.	No change. The arrows you are referring to are UML dependency relationships and not flow directions. We understand this could be confusing at first glance. Technical Specifications are dependent on the results of Work in Progress. Technical Specifications are for public view and work-in-progress is restricted by user authorization. We believe your comments are related in the model.
7.7	Martin Bryan	6/06/200	526	527	The Subscribe to Related Repository use case mentioned here does not appear to be defined in this document, but no reference is made to another document.	Thank you. Sentence deleted.
7.8	Martin Bryan	6/06/2000	General		There no mechanism by which a Guest User can request information about technical specifications or other proposed or accepted change to an object that he has determined Is needed as part of an application. Related to this, there is no mechanism by which ISVs can identify which Software Agents are related to which repository objects, or to record which of their software agenets may need to be updated when a new version of a particular object is proposed / created.	1) Figure 1 clearly shows there is a use case allowing the guest user to retrieve items. The detail behind this Use Case will be elaborate in Part 2 and Part 3 of the ebXML Registry and Repository specification.
7.9	Martin Bryan	6/06/2000	General		There is no model of the APIs that will be required too provide interfaces between the identified actors and the repository.	Correct. That will be defined in Part 4: Design. It appears that is not an understanding of the UN/CEFACT methodology for model development. This is briefly covered in the Introduction line 95 and Figure 1. Whether to actually define each Part of the overall ebXML specification is being discussed.
8.1	Mike Rawlins	6/06/200	3	3	Issue or rationale: Inconsistent versioning between different specifications, yours starts at 1.0. Inconsistent with "ebXML Specification Approval Process", May 30, 2000, section 2.1 Suggested change: Set next version to 0.x, with note of explanation. Set final published version at 1.0	No Change. At the time of the draft of this specification, 1) there was no Approval Process and 2) we felt that the document when released would be called v1.0, and that the issue date was sufficient to ensure that people were clear of which version they were looking at.
8.2	Mike Rawlins	6/06/200	126	153	Issue or rationale: Omission of dependency on "ebXML Requirements Specification" Suggested change: Add reference to dependency on "ebXML Requirements Specification"	OK. Sentence add before Line 127: Each ebXML Registry and Repository specification (Part 1 through Part 4) is based on the business requirements as documented in the ebXML Requirements Specification.
8.3	Mike Rawlins	6/06/200	141	143	Issue or rationale: Inappropriate technical detail for functional specification document dealing with business domain Suggested change: Strike sentence "Therefore the XML interfaces ... XML document responses."	OK. Despite the fact that there were many business people in the meeting when the sentence was drafted.
8.4	Mike Rawlins	6/06/200	154	154	Issue or rationale: These are more references than "Conventions and Terminology". Suggested change: Change title to "References"	OK.
8.5	Mike Rawlins	6/06/200	157	160	Issue or rationale: Incomplete references Suggested change: Include URLs to references	No change. Adding a URL creates a maintenance nightmare if URL changes over time.
8.6	Mike Rawlins	6/06/200	163	404	Issue or rationale: Section 2 on Actor Relationships and Section 3 on Domain Use Case seem to be based on the proposed development process and organization (distinct from TMWG modeling methodology) that TMWG/SITG have been working on for CEFACT/EWG and X12. That process and organization have yet to be approved. Even if they are, there are other organizations that will wish to host a repository that implements this specification that do not have the same actors or use cases. These sections are too detailed around one specific business domain (this proposed organization and process), and leave out details of other similar domains which would also use the repository. Sections 2 and 3 need to made more generic to accommodate different other business domains, i.e, other organizations and processes. Suggested changes: Rewrite all actor descriptions to indicate that the actors detailed are roles or functions and not necessarily specific unique entities. [NOTE: This may be implied by UML or the modeling methodology, but if so it needs to be made explicit in this document.] This is particularly important for the actors within the registration authority. Review organization and processes of existing bodies using modeling (Hl7, ACORD, RosettaNet, OAG) to discover if there are other functions or roles (actors) which are not included in this breakdown.	The UN/CEFACT methodology is based on Rational’s Unified Process (RUP) which is a common framework by which methodologies can be defined. The UML Profile used within the context of this methodology was complete and is being used. Who needs to approve this anyway? SWIFT’s recommendations above seem to accommodate your concerns. The fact that an actor is included doesn’t suggest that it is instantiated. Regarding roles and functions, functions are more represented by the use case itself, roles is more represented by the association of the actor to the use case and the actor is the unique entities (as you term it) that interacts with the use case. Specify actors using UML use cases provides a way to identify if the actor has a unique business requirement.
8.7	Mike Rawlins	6/06/200	166	166	Issue or rationale: Grammar Suggested change: Should be "role based"	OK.
8.8	Mike Rawlins	6/06/200	172	174	Issue or rationale: Unclear about just what a "guest user" is. Suggested change: Add further clarification about what a guest user is.	Added to Line 174: “…organization, but has very limited responsibilities and privileges, e.g., access rights.”
8.9	Mike Rawlins	6/06/200	177	179	Issue or rationale: Unclear about scope of "as defined by ISO 11179" and definitions. User is forced to refer to ISO 11179 for definition(s). For example, it is unclear how non-profit organizations and government agencies fit into the Actor Relationship class hierarchy. Are these "corporations"? Suggested change: Include specific ISO 11179 definitions.	Changed: (for definitions of SO and RA, see ISO 11179). Yes, government agencies and not for profits are corporations in this context. We struggled with this in Brussels to find the best word. Corporation is what stuck.
8.10	Mike Rawlins	6/06/200	182	186	Issue or rationale: Same as 177-179, still unclear about what specifically a "corporation" is in this context. Suggested change: Add more explicit definition either here or in previous section.	Replace Line 183 with: A corporation is a collection is individuals that work together to achieve a common goal through its policies, processes, and resources.
8.11	Mike Rawlins	6/06/200	197	202	Issue or rationale: ISV actor description excludes development groups within a "corporation". Suggested change: Change "ISV" actor to "developer" actor, and include mention that this could be an internal corporate function rather than an external entity. This, again, is more along the lines of making these actors' roles or functions, rather than specific entities.	Changed to Software Developer
8.12	Mike Rawlins	6/06/200	198	198	Issue or rationale: ISV produces software that meets the needs of the corporation, not the business domain expert. Suggested change: Change to "meets the needs of the corporation, as expressed by the business domain expert".	OK: Changed to The Software Developer produces software that meets the needs of the corporation, as expressed by the business domain expert.
8.13	Mike Rawlins	6/06/200	198	202	Issue or rationale: Sentence "The business needs of the Business Domain Expert ... Registration Authority)." Suggest specific entities and processes. Also, sentence is too long. Suggested change: Strike, or qualify with "depending on the organization and processes, these needs may be communicated" rather than "are communicated".	The model will be changed to add the unidirectional associations (which are based on the RUP framework), and add verbiage to explain this. Deleted sentence.
8.14	Mike Rawlins	6/06/200	204	206	Issue or rationale: Same issue as 177-179. Unclear about just what a "Registration Authority" is. Suggested change: Include more specific definition of "Registration Authority".	Per 11179
8.15	Mike Rawlins	6/06/200	214	215	Issue or rationale: Several issues with the sentence "These role players ... Process Modeling". a) Unclear about whether this is the "UN/CEFACT/TMWG UML Profile and Methodology" mentioned in line 135, or a different document. b) There is an implied dependency on this methodology that is not mentioned in section 1.2 c) Same issue as general comment on lines 163-404 regarding sections 3 and 4. Other organizations and processes need to be supported beyond just this one. Suggested changes: a) Make consistent document references, and include in section 1.3 b) Include dependency in section 1.2 c) Same comment as 163-404.	a) Changed to UN/CEFACT/TMWG UML Profile and Methodology and role players to Actors, b) now referenced, c) don’t agree that they should be specified here versus Part 2.
8.16	Mike Rawlins	6/06/200	204	254	Issue or rationale: ebXML works with "core components", not "common business objects", and they are not the same. Suggested change: Change all occurrences of "common business object" to "core component", and remove parenthetical references to "core component"	This is still in debate. No change.
8.17	Mike Rawlins	6/06/200	204	254	Issue or rationale: Same issue as general comment lines 163-404 sections 2 and 3. Too specific about one particular type of organization and process. Suggested change: Make more generic.	Without specific recommendations, we find this task request to be inappropriate. In addition, specify this high level detail about actors is appropriate as it leads very well into Part 2: e-Business Requirements.
8.18	Mike Rawlins	6/06/200	255	259	Issue or rationale: Unclear about definition of "Industry Consortium". Suggested change: Add more detailed definition of "Industry Consortium"	See SWIFT’s comments and changes.
8.19	Mike Rawlins	6/06/200	306	307	Issue or rationale: Sentence "The SO must be ... use case." Implies a specific policy of the registration authority. Out of scope for this document. Suggested change: Change to "Depending on RA policies, the SO may be..." rather than must be.	Changed.
8.20	Mike Rawlins	6/06/200	322	324	Issue or rationale: It is clear that the functionality needs to supported. However, this implies specific policy and procedure of RAs which might use the R&R, which might not be accurate. Suggested change: Add qualification to make this dependent on policies and process of the RA.	Changed “can” to “may”, as it is important to allow this classification, since it is very probable that an RA may misclassify an object.
8.21	Mike Rawlins	6/06/200	336	337	Issue or rationale: "May" unclear. Suggested change: Add qualification "Depending on policies of the registry host..."	Others had the same comment. Changed.
8.22	Mike Rawlins	6/06/200	348	351	Issue or rationale: Several a) Implies a testing and certification process, that may or may not exist or be used b) States that software components (presumably executable code) can be registered and downloaded. This adds technical and business complexity to the operation of the R&R. Suggested change: Strike paragraph.	a) We think this is an open issue as this was debate at the first San Jose meeting and there seemed to be positive discussion in favor of certification, b) Why is this more complex?
8.23	Mike Rawlins	6/06/200	354	354	Issue or rationale: Unclear about what makes specifications "good" Suggested change: Strike "good"	Already changed.
8.24	Mike Rawlins	6/06/200	358	359	Issue or rationale: Extraneous business detail not appropriate for the scope of this document. Suggested change: Strike	OK.
8.25	Mike Rawlins	6/06/200	363	363	Issue or rationale: Sentence about background check implies policies of RA that may or may not be relevant. This is irrelevant, unrelated detail beyond the scope of this document. Suggested change: Strike, or change to append to the previous section "The RA authorizes ..., according to criteria established by the RA".	See comment from Robert Miller and changes.
8.26	Mike Rawlins	6/06/200	367	371	Issue or rationale: Too much detail about a process based on assumed or hypothetical policies of the RA. Suggested change: Strike, or change to mention that some RAs may have policies that withhold public access to submissions until reviewed by the RA. Therefore, functionality to limit access until review is performed must be supported.	We changed the text to include “may” in several sentences.
8.27	Mike Rawlins	6/06/200	403	404	Issue or rationale: Extraneous business detail not appropriate for the scope of this document. Suggested change: Strike	Others made similar comments. Deleted.
8.28	Mike Rawlins	6/06/200	435	435	Issue or rationale: reference is to an "ebXML-compliant" specification, and not to an RA standard or specification that may or may not be "ebXML-compliant". The purpose of this document seems to be to enable a network of interoperable registries and repositories, i.e., R&R that are "ebXML-compliant", and NOT an ebXML R&R. This sentence implies the latter. Suggested change: Change "an ebXML-compliant specification" to an "approved standard or specification"	OK. Changed.
8.29	Mike Rawlins	6/06/200	447	465	Issue or rationale: Same as 435-435. The R&R is not an "ebXML R&R" designed to support "ebXML Technical Specifications" or items that meet "the requirements of the ebXML Business Process Metamodel", it is an R&R that is ebXML-compliant that may or may not contain any ebXML artifacts, or artifacts that are compliant with ebXML. Scope here is way too narrow. The goal should be a single network of linked R&Rs that contain artifacts that are both compliant and non-compliant with ebXML, with compliance status noted as an attribute of the artifact. Process description is too detailed around development of an ebXML technical specification. Suggested change: These lines need major re-write to address the issues noted. Make them more generic, and not just applicable to the development of ebXML or ebXML-compliant artifiacts. Change "technical specification" to "public item". This makes the package more generic, and makes the submission of private items not intended to be subject to a standards development process or compliance criteria more straightforward.	We don’t see what the problem is with this verbiage as several scenario examples are represented (i.e., ebXML Specification and non-ebXML Specification which covers everything else). The point of this section is to show that User Interface workflows exist, which will be elaborated on in Part2.
8.30	Mike Rawlins	6/06/200	477	478	Issue or rationale: "especially ... cached in memory." is an implementation detail inappropriate for the scope of this document. Suggested change: Strike.	OK. Entire sentence deleted.
8.31	Mike Rawlins	6/06/200	490	497	Issue or rationale: "check-out/check-in" implies that developers will use the repository in the same fashion as a source code library. Unclear about the items that are checked-out and checked-in. It makes much more sense to make the developer's access read-only, and any developed artifacts to be handled through the submission services. Having a quasi-public R&R serve as a source code library for private entities adds unnecessary technical and business complexity. Some R&Rs may wish to provide this facility, but it is clearly beyond the scope of this specification. Suggested change: Strike references to check-out/check-in. Strike paragraph 494-497.	This was debated heavily in Brussels and the team comprised by making this an optional service under repository, however the interfaces still should be defined. No change except for the deleted word “what” in line 495.
8.32	Mike Rawlins	6/06/200	516	518	Issue or rationale: This is an implementation detail inappropriate for the scope of this document. Suggested change: Strike.	This debated heavily in Brussels the team felt that the simplest case should be detailed. No change.
8.33	Mike Rawlins	6/06/200	567	569	Issue or rationale: Similar to others. R&R needs to support multiple organizations and processes, not just ebXML. Suggested change: Change "events; e.g. ... model" to "events, dependent on policies and procedures of the Registration Authority."	Added: …events, dependent on the policies and procedures of the RA; e.g., ….”
8.34	Mike Rawlins	6/06/200	577	583	Issue or rationale: Unclear about what this appendix is. These appear to be references with embedded URLs, but they are not accessible as links in the PDF. They also appear to be somewhat duplicative of the references in section 1.3 Suggested change: Merge this list of references with those in 1.3, and strike this appendix. Include specific URLs after embedded URLs.	Links are removed altogether. No URLs will be specified.