[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] [Profile for WS] Comments - part 1
Kathryn Breininger
Boeing Library Services
425-965-0182 phone
Hi all,
Sorry for the delay in replying, I see that
comments are still accepted so, here some general comments on the rr profile for
ws.
Line 201 – missed the purpose
section.
Does this
document a profile for WS or WSDL? This is not really clear in the document.
This section could help us to better define the document and the reader to
understand.
IMO the target is to provide the storage for WS using WSDL metadata, so WSDL profile seems to me more appropriate. WS vs WSDL rr profile!?!
Line 261 Section 2 – in according with Anne and with the previews comment, I think that we have to add a WSDL class in the Information Model. (The WSDL is the *glue* for all WS elements in the registry that actually seem a little bit *dispersed*)
Line 513 – the mapping isn't complete. What about Operation, Message and Type classes.
(Line 518 – I don't find it so complex, try to take a look to the CCTS IM ;)
Line 521 – General comment: I suggest another representation of the mapping. IMO a table seems more appropriate here that a sequence of sections (see the profile template). For example:
The following table lists the whole mapping profile for WS source model with the correspondent object type:
Source
Concept Source Parent Concept ebRIM Object Type
Name ebRIM ObjectType ID* Comment
WSDL
- WSDL
EO:WSDL
wsdl:service
Service EO:WSDL:Service
Wsdl:Port
Service Port EO:WSDL:Service:Port
Wsdl:Binding WSDL
Binding EO:WSDL:Binding
Wsdl:PortType WSDL
PortType EO:WSDL:PortType
Wsdl:Operation PortType
Operation EO:WSDL:PortType:Operation
Wsdl:Message
Operation Message EO:WSDL:PortType:Operation:Message
Wsdl:Type Message
Type EO:WSDL:PortType:Operation:Message:Type
Table 1: Core Information Model ObjectType
profile
*EO=urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExtrinsicObject
Attributes
definition
In
the following table are listed the attributes for WS concepts:
Source
Concept Source Attribute ebRIM
Attribute* Comment
Wsdl:service
id id It MUST have as prefix the targetNamespace for the
wsdl:service element, followed by a suffix of “:service:<service name>”
where <service name> MUST be the value of the name attribute of the
wsdl:service
element.
name
name
documentation
description
…
Table XX: Core Information Model Attributes for defined
ObjectTypes
* Slot parameters corresponding to (“Slot name attribute”, “Slot type attribute”, “admitted values”)
Line 587,683 – I suggest using the registry object objectType attribute in preference to the classification.
Line 858 – As for object mapping I suggest the table rappresentation for association as follow:
Associations
definition
The
following table defines the association mapping between the source model WS and
ebRIM:
Association Source
Object Association Target
Object [ebRIM] Association
Type Name
Comment
Service
Port -
- ServiceBinding Service's attribute is
used.
Port Binding
Implements
Canonical ebRIM
association
Binding
PortType
Implements
Canonical ebRIM
association
...
Table 5: Association Information Model AssociationType
profile
The sourceObject, as for the target object, attribute value of the rim:Association MUST contain as value the id of the object instance.
Line 890 – not sure about what you would to say here. Are these files generated by the "registry" or they are submitted directly by users?
General Comment: I suggest introducing some "standard" classifications for WS like Business Process context, Industry context, geopolitical context, etc.
Et voilà.
Many thanks Farrukh for the really great
work!
Best regards,
Ivan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]