Steve,
Thank you for detailed feedback you posted in the Working Group Documents area.
Following are responses to your comments. In some cases further elaboration of the points you made would be helpful. We have highlighted requests for further elaboration in bold.
Value Lists
Quite a few of your comments relate to the value lists specified for certain types. For example, for the RemarkType class, you commented that, “This list would need to be expanded.” The RemarkType class is a UML Code List stereotype class. In TransXML, we are using two types of UML stereotype class for value lists: Enumerations and Code Lists. For UML Enumerations, the value list is predefined and fixed. Enumerations cannot be extended or modified. For UML Code Lists, the value list is flexible. It can be extended, modified, or completely replaced depending on the requirements of specific producers and consumers.
In TransXML, enumerations are used in cases where there is a universal consensus on the value list. For example, the TimeChargeUnit enumeration stereotype class has the values “days” and “hours”. In contrast, Code Lists are used in TransXML in cases where there is not likely to be a universal consensus on the value list and therefore flexibility is required. The values provided in the TransXML model for code lists are shown for purposes of illustration only.
Validation of the choices for the use of Enumerations versus Code Lists is important. Please let us know if you see cases where a Code List is used in an instance where there is a previously-defined standard value list that should be used as an Enumeration instead.
Responses to your General Comments
Regarding your General Comments, a factor in the organization of the packages is the specific data flows that were selected to be addressed by the TransXML project. In cases where a class is relevant in multiple data flows, the intent is for a single, uniform representation of that class to be shared across the packages for those data flows. A class that is shared is defined in one package and referenced by the other packages that need it. The attributes of the shared class should be consistent across all packages that reference it. The "home" package for a class is shown in the narrative definition of the class. It is also shown in the class diagrams with the notation "(from [package name])" underneath the class name in the class box. For example, the MaterialSamplingAndTesting package uses the ConstructionProject class defined in the ConstructionProgress schema.
Differences observed between the classes shared between the BidPackage and ProjectConstructionStatus models posted on April 21, 2005 and the ConstructionProgress and MaterialSamplingAndTesting models posted on May 3, 2005 may have been due to the fact that these shared classes were evolving throughout the model development. In the final drafts of all four construction/materials business area models, there will be no differences between the definitions of a class that is shared across packages.
If there are cases where your staff has identified shared classes that are inappropriately shared, can you please elaborate.
Responses to your Specific Package Comments - Bid Package
Regarding your comments about the ConstructionType class in the Bid Package, it was not feasible within the scope of this TransXML project to develop a consensus on a uniform set of construction types to be used by all organizations that may use the schema. This could be an objective for a future TransXML initiative.
Responses to your Specific Package Comments - Construction Progress Package
Regarding your comments about the Construction Progress Package, can you be specific about which attributes definitions are ambiguous?
--- Regarding comment (1):
Organization code - Please elaborate. You indicate that this should be in lieu of the districtOffice attribute. Is this an alternative division scheme within agencies? What is the data type? Would there be an associated code list or enumeration stereotype that defines the valid values for an agency?
Employee ID - We will add an employeeID of type String.
Email address - Please see AgencyStaffMember.contactInformation.emailAddress.
Inspection, Sampling, and Testing Certifications – Excellent point. We will add classes for certification information for both agency and organization (e.g., contractor) personnel.
--- Regarding comment (2):
Please elaborate on the incentive/disincentive information for the ConstructionProject class. Incentive/disincentive information related to contract time is currently represented in the ContractMilestone class. What additional information should be in the ConstructionProject class?
--- Regarding comment (3):
The intent of the Contract.constructionStatus and ConstructionProject.constructionStatus attributes are to indicate the current construction status of the contract and project, respectively. These attributes are associated with the ConstructionStatus code list stereotype class for which example values are shown.
You propose a list of date attributes. The ContractEvent class is intended to represent notable events on the contract such as the Construction Start Date. Is there a requirement for a similar class to track notable events on a project or is the contract-level event history sufficient?
Regarding Percent Complete, please elaborate. what would this be based on? Based on time charged with respect to the current authorized contract time? Based on time charged with respect to the contractor's time schedule? Based on amount paid to date or earnings to date with respect to the current contract authorized amount? Are you referring to the contract level, the project level, or both?
--- Regarding comment (4):
The ContractorPersonnelType class is a code list stereotype. The values shown are for illustration purposes only.
--- Regarding comment (5):
Some attributes of the DailyWorkReport class are attributes such as the reportDate and reportStatus that are related to the daily report as a whole. The weather-related attributes in the DailyWorkReport class will be separated out into a DWRWeather class. We recommend retention of the DailyWorkReport class with the attributes that are specific to the report as a whole.
--- Regarding comment (6):
The DWRContractor class enables the association of contractor organizations that are on site on the date of the DailyWorkReport. In the model, this is represented by associations between the DailyWorkReport, DWRContractor, and Organization classes. The DWRContractor context diagram on page 45 of the ConstructionProgress package document dated May 3, 2005 does not display the association between DWRContractor and Organization. This will be corrected.
--- Regarding comment (7):
The personnel information for the contractor supervisor that is on site is represented through the association between the DWRContractorSupervisor and OrganizationEmployee.
--- Regarding comment (8):
The ItemPriceAdjustmentType class is a code list stereotype class. The values shown are for illustration purposes only. We will add “royality”, “qualityAssurance”, and “smoothnessIncentive” to the example values in the model.
--- Regarding comment (9):
A publicWorkLicenseNumber attribute of type String will be added to the Organization class.
The prime contractor on a contract is represented by the Prime Contractor role of the association between the Contract and Organization classes. This is shown on the Organization Context Diagram in the ConstructionProgress package document. Additional materials-related roles for Organizations are shown on the Organization Context Diagram in the MaterialSamplingAndTesting package document. Subcontract information is not explicitly represented in the ConstructionProgress or MaterialSamplingAndTesting models.
--- Regarding comment (10):
Civil rights monitoring aspects such as certified payrolls are not within the scope of this first TransXML schema development project. Civil rights monitoring data could be an objective of a future TransXML initiative.
--- Regarding comments (11) and (13):
The RemarkType and WeatherConditionType classes are code list stereotype classes. The values shown are for illustration purposes only.
--- Regarding comment (12):
The StaffWorkType class is an enumeration stereotype class, so the values listed are intended to be comprehensive. Please elaborate on the additional values that would be required.
Responses to your Specific Package Comments - Material Sampling and Testing Package
Regarding your comments on the Material Sampling and Testing package.
--- Regarding comment (1):
Excellent points. We will further elaborate this area. Some aspects that you mention are not modeled and some should be modeled more clearly.
--- Regarding comment (2):
The MaterialCategory class is a code list stereotype class. The values shown are for illustration purposes only.
--- Regarding comment (3):
Please elaborate on the attributes of borrow sources.
--- Regarding comment (4):
The MaterialPlantType class is a code list stereotype class. The values shown are for illustration purposes only.
--- Regarding comment (5):
An instance of the MaterialTest class represents a standard test (ReferenceTestMethod class) that is performed on a standard material (ReferenceMaterial class), further qualified by any contract-specific sampling and testing requirements (ContractSampleAndTestRequirement class). The test attributes you are looking for are probably in the ReferenceTestMethod class. We have not identified any additional descriptive attributes that are required for the MaterialTest class. If you have additional attributes in mind that are not addressed in the ReferenceTestMethod, ReferenceMaterial, or ContractSampleAndTestRequirement classes, please elaborate.
--- Regarding comment (6):
The MaterialType class is a code list stereotype class. The values shown are for illustration purposes only.
--- Regarding comment (7):
We will add certification identifiers to both sample and material tester qualifications.
--- Regarding comment (8):
The SDOType class is a code list stereotype class. We will add ASTM to the list of example values.