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: RE: Comments on 0.5 and DTD's


David,
I know that I missed entering some of your written comments (below) into the
v0.5 Registry Spec review notes.  As some of your written comments were also
brought up by others in the mtg, they should have been captured.  Could you
please review your note below, my minutes from yesterday's meeting, consider
your recent discussions with Farrukh, and then let me know what else I
should add to the Spec Review Issues list.  I want to make sure that all of
our comments and suggestions are dutifully captured.
Thanks,
Joel

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Tuesday, September 19, 2000 11:39 PM
To: ebxml repository
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.



[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