We recommend that the Finnish national body votes YES for the progression of "ISO/IEC DIS 13235-1.2 ODP Trading function - Part 1: Specification" provided that the following comments are resolved:
The type repository function standard that will be in CD ballot after the January 1997 meeting will give the corresponding definition. Repetition of this kind should be avoided in order to protect ODP-RM consistency.
Resolve means that the trader utilizes the services of naming function. Instead of defining a resolve operation, a reference to naming services should be given. The Naming framework standard is currently in the CD ballot phase.
This standard should not specify the type repository interface. Even in the type repository function standard this would be too CORBA specific. Please refer to the current working draft of the type repository function.
Use of CORBA::TypeCode seems inappropriate. Replace with "any".
The requirement that traders remember identifiers of all recent requests is too restrictive. The text in Clause 8.2.8.1. on lines 16-20 (from under the piece of IDL to the end of the clause) seems more suitable to a tutorial than to a standard. Remove the text, or formulate it as an example in a note.
The example expects that search is always sequential. There should be somewhere a hint that also concurrent searches can be started. Add a sentence that says "Searches can also be executed concurrently."
This operation is not interesting for the trader behaviour at all. Move the operation to clause 8.2.6.
The modification operations for attributes on the admin interface should be collected under a single operation that has a parameter for the modified attribute. The list of attributes is not necessarily complete, and the current style makes all modifications costly.
At the first line, replace CORBA by ODP trading function. Remove the last sentence of the second paragraph.
Requirement for ASCII is an unnecessary restriction. Replace ASCII by ISO 8859 Latin1 character set.
Replace in paragraph 5
"A group of Interworking Traders is a community of traders,
with their respective importers and exporters. For traders
to be a member of an established group of interworking traders:"
by
"Traders can interwork by establishing a trading community
where:"
The structure of the enumerated list of policies is not clear. The clause should start by a description of the relationships between the policies. The text should also state whether the policy listing is complete or open ended.
The term trading system is undefined at this point of text.
Service offers are occasionally referred to include "computational interface identifiers" instead of "interface identifiers". Examples of such occasions can be found in clauses 7.2.1.1. and 7.2.1.2.
In a formal specification the phrase "A service type is AT LEAST an interface signature type." is too vague (clause 7.2.3). It leads to difficulties in the following text. We recommend that the text is slightly changed:
"A service type definition consists of an interface signature type, a set of service property definitions, and a set of rules about the modes of the service properties. The set of service properties is governed by the set of mode rules. Modes are normal (read and write but optional presence), read-only (read but optional presence), mandatory (read and write mandatory presence) and read-only, mandatory (read only, mandatory presence). "
If further reservations are felt necessary a note "Note: The set of properties and rules may be empty." might be added.
This definition expresses that the set of mandatory properties has semantics also on the level of service type, not only on the level of individual property definition. This semantics is then used in clause 7.2.5.
The statement is in wrong viewpoint. Replace with "The trading system is defined in clause 7.3."
Remove the sentence "The trading system is a system managed by a set of interworking traders." It is in wrong viewpoint.
The statements about the relationships between information and computational viewpoint specifications are contradictory. The text in clause 7.3. allows many information nodes to be mapped to one computational trader object. However, clause 8.1.2. states "an information partition shall correspond to one and only one trader object".
It has been stated in computational viewpoint that the offer id is always generated by the trader. This line suggests, that also the exporter can generate offer identifiers. Delete the sentence.
Does the text "is not connected to" mean that a trader has no links to other traders or that no other trader has links to this trader? If no links to any direction are allowed, the autonomy of the trader is overlooked. Replace "is not connected to" with "no longer has edges to other nodes".
The sentence "If an attempt is made to begin ..." is misleading. Has the end of the sentence "without changing the state of the trading system" any semantics here?
In Clause 8 the IDL specifications refer to CosTrading and other concepts that appear only in Annex A. These terms should be mentioned in the beginning of Clause 8, just before 8.1. starts. For example, the term Lookup is used before it is introduced to be a name of an interface.
Replace the first chapter by:
"The policies expressed
in the enterprise viewpoint, are expressed in computational viewpoint
as operation parameters and trader attributes. Some parameters and
attributes can be expressed as constraints."
The sentence at line 6 about internationalizability should be a technology viewpoint statement. Move this sentence to the Clause 5 (Overview).
Under the table there is a sentence
"No combinations of the preferences are permitted."
Does "combine" mean here operands like "and" or "not",
or does it mean nesting of expressions?
Items like request_id and starting_trader are not policies but parameters. The list in this table should be separated into two list: one for policies, and one for other aspects. The preparatory text should tell what the scopes of these lists are.
Why exact_type_match policy is flagged to involve importers only, and not traders also? We expect this to be an unintentional omission. This was earlier one of the first trader properties identified.
What does "override" actually mean in this context? Override appears also in the tables. We would prefer more exact wording here.
The section of text that starts "Recall ..." and ends to "The follow policy ..." seems unnecessary.
"Importer policies" seems to be an undefined term.
The clause 8.2.9 unnecessarily repeats attributes that are introduced in clauses 8.2.7.4.1. and 8.2.7.4.2. The clause should be restructured so that the text first introduces what these attributes are for. Second, the text should indicate that the clauses 8.2.7.4.1. and 8.2.7.4.2. introduce some trader attributes. Third, the text should introduce the three last items of the table as new attributes. Finally, there should be a sentence that indicates that new attributes can be introduced, that the list is not necessarily complete.
The text uses terms like object reference and nil instead of the correct ODP terms.
The appearing "ANY value", although common in CORBA text, does not feel correct here.
The sentence "The behaviour of such traders in such circumstances is not specified by this standard." should be removed. Instead, there should be a statement that a trader either serves according the specification or refuses the service.
The editor is requested to find doubled dots in the end of sentences, and extra white space before the dot in the end of sentences.
Last line should mention Annex D instead of Annex C.
The last reference has not been fixed yet.
Is it not a requirement to list the new term definitions of this standard?
The chapter under Figure 1 should say "can" and "imply" instead of "could" and "would imply".
The sentence "A user of a trader ..." is unclear.
The english language explanations of the Z specifications should be separated out with a suitable layout. We suggest, that such explanations are transformed to notes.
First sentence is difficult to read and should be removed. Interface signature type is defined in ODP-RM Part 3.
Second sentence defines something based on nodes and edges. Those have not been defined yet. Replace the sentence by "Property type has subtypes."
Replace "A property type is identifiable within a trading community." by "The scope of a property type definition may be a single trading community."
Typo in Z. Is it ServiceType or Service_Type.
Consider removing some of the clauses, because they unnecessarily repeat the same concepts. One of these should be sufficient. Other clauses can refer to it. Also ODP-RM Part 3 includes this definition, and a reference to that should be included.
Replace TradingSystemConstraint with TradingConstraing. The term TradingSystemConstraint distracts readers.
Remove the word "supplied".
Replace with "to add a new property which already exists in the service properties".
The term "read-only" seems to distract readers. We recommend the term "immutable" to be used instead. This term probably appears also in naming and at least in type repository. Therefore, "immutable" would bring some consistency between standards.
At line 8, replace "simpler" by "simple".
The sentences in the table are broken.
Replace "I=Import" by "I=Importer".
At line 2, replace "than" by "then".
The three items in the list of exceptions appear all twice.
All subclauses start by the full interface IDL, then the operation IDLs are repeated again in the subsubclauses. A third repetition appears in the annexes.
The expression "if the 'constr' does not obey the syntax" needs a supporting reference to the annex.
Reference to section 2.2. on page 3 is faulty.
Remove comments from the IDL.
The standard should not predict what most future implementation will look like.
Reference to "clause 5.3.6. on page 34" is invalid.
The sentence "Other than the preceding rules, ..." is odd.
The note is no more needed.
Extra parenthesis at the end of the third bullet in the second bullet list.
In the 3rd paragraph, first bullet, there are some extra words: "b is may add".
Replace "Thest" by test.
Forward and propagate? Which functionalities these refer to?
In definition of "exist", replace "property" by "property name".