Subject: Comments on 0.5 and DTD's
Some notes: The UML diagram in Figure 1. This asks as many questions as it solves. The relation of actors is missing - so you don;t know who is allowed to do what when. Suggest this be two diagrams that show roles - and clarify that all actors are allowed to do most of the actions - particularly Query! Some more explanatory text would help too. Page 13 line 370 and line 393. The two TPA docs'. <BusinessInterface> <ServiceInterface InterfaceId = "Registry"> 372 <OrgName Partyname = "Registry">Registry</OrgName> 373 <TaskName>RegisterRequest</TaskName> 374 <ActionMenu> 375 <Action id = "register" Type = "basic" Invocation = "asyncOnly"> 376 <Request> 377 <RequestName>RegisterRequest</RequestName> 378 <RequestMessage>RegisterRequest</RequestMessage> 379 </Request> 380 <Response Required = "yes"> 381 <ResponseName>RequestAcceptedResponse</ResponseName> 382 </Response> 383 <ExceptionResponse> 384 <ExceptionResponseName>RequestErrorResponse</ExceptionResponseName> 385 </Response> 386 </Action> 387 </ActionMenu> 388 </ServiceInterface> 389 </BusinessInterface> 390 Seem highly redundant - the word "Registry" appears everywhere and most of the information appears to be functional commonsense. Suggest we replace this with a set of bullet points stating the functional behaviour of Registry. Noone is going to look this up anyway - as bootstrapping is impossible (Catch 22). Since the TPA is highly draft material - lets have the functional bullet points instead. Much clearer. Section 5.3 Ad Hoc Query Can we be a little more clear on what an ad hoc query is? So we know the scope of what we are avoiding doing, and hence what is in scope... Section 5.4 Keyword Search This again needs clarifying, because some keyword style search may be needed prior to Tokyo - for instance to retreive all CC's within a specified business domain.... Section 5.5 [clip] ManagedObjectRef element contains a URI for the object matching the query in the repository. 535 The client can use the URI to retrieve the object. Note that security issues will be addressed by 536 ebXML TRP security mechanisms that are outside the scope of this document. 537 [clip] I do not follow this at all! Its contridictory - either we are using TRP or not. If we use the URI, we by-pass the TRP completely and the security mechanisms! The Interface Primitives 0.21 draft solves this by providing direct mechanisms here - and not requiring indirect work arounds. The sample DTD's provided I thought were just temporary placeholders! I'm not at all sure these do anything useful. We're missing goups of detail - including linkage to submitting organization, access authority, and parts (error response) seems to be re-inventing DASL and other work in this area. Not to mention the ability to consistently identify the underlying reference elements that allow the Repository to know if this exists already, if it is an update, what domain of the content it belongs to, classification model, and so on and so forth. So - OK - these are rough drafts based on the UML action models. It seems to me though that the better approach is to create SINGLE multi-purposed DTD structures that can use VERBS to define the context. This makes the interface MUCH simpler for people to assimulate and utilize. Just because UML has 20 action models - does not mean we have to have 20 DTD's.... I have a conflict meeting at 10am so I probably will miss the conference call today too. Thanks, DW.
Powered by eList eXpress LLC