RE : [regrep] [Joe's Comments, Part 1] RE: [regrep] RE: ACTION ITEM

["BEDINI Ivan RD-BIZZ-CAE" <ivan.bedini@francetelecom.com>]

Hi all,
Some comments on Joe's comments part 1.

Line 261: This chapter is called "WSDL Information Model Overview" here,
but in the earlier list of chapters it was described as "provides an
overview of the Web Services information model.". Recommend changing the
earlier description to be ""provides an overview of the information
model for Web Services description within an ebXML Registry", and
changing the title on line 261 to "ebXML Registry Information Model for
Web Services".

[IB] - IMO "Web Service description" could only mean that we are
decribing WS by their WSDL instances, so the Source information model is
"WSDL IM", which is what effectively we are using as source mapping.  

Chapter 3, General: I recall we discussed on a TC call the idea of
removing this section, and having the reader refer to our specs. I
recommend instead that we focus this chapter only on the Service
Information Model and its classes, describing each class as we do in the
ebRIM spec (but perhaps with less detail) 

[IB] - I agree, I've already changed the profile model.

Lines 514-515: Does the mapping have to stop at the WSDL PortType? Why
couldn't we have Operations, Messages, and Types (and Message Parts) as
ExtrinsicObjects in the registry that are reused among various
PortTypes?

[IB] - +1

Line 549: Same idea as with line 535. & Line 565: Same idea as with line
535.

[IB] - IMO it's the case only for the Id attributes. Here the mapping is
"the service name/decription attribute must bicome the rim:service
name/description attribute". The fact that the name is mapped to the
name => the name value MUST be the same for boths (otherwise what is the
aim of the mapping ?!? It could be the same thing that saying that a
user name instance is mapped to rim:person name and after I put there
his email address ;-). 

Line 587: Recommend including a figure that visually depicts the
following lengthy description: "Classifies the rim:Service for
wsdl:service by the Service ClassificationNode child of the WSDL
ClassificationNode in the ObjectType ClassificationScheme.". Whew!!!
(same for later similar instances, such as line 683)

[IB] - Thanks joe, now it's more clear ;-)
Suggest to use the Profile Template construct. It's aim is just for
trying to clarify the RIM classification complexity. If we define all
object types needed for managing the domain and after we define service
instances of type WSDL:service (that is defined previously), may be it
results more simple to understand. 

Chapter 4, General: I recommend organizing this section a bit more
consistently. Perhaps we can list the following sub-subsections for each
subsection (a subsection would be 4.3, for example):

[IB] - I suggest the profile template organization. It also try to
follow the ebRR specs organisation and needs for profiling. A reader can
find a correspondence between the profile and the specs and it can be
useful. 

Regards,
Ivan