| Title: | Report of May 2002 Meeting of ISO/IEC JTC1/SC34/WG3 in Barcelona |
| Source: | SC34/WG3 |
| Project: | All SC34 Projects |
| Project editor: | All SC34 Editors |
| Status: | Recommendations of WG3 meeting in Barcelona |
| Action: | |
| Date: | 2002-05-22 |
| Summary: | Recommendations of WG3 meeting in Barcelona |
| Distribution: | SC34 and Liaisons |
| Refer to: | |
| Supercedes: | |
| Reply to: | Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Information Technology Services Bldg. 9113 M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 E-mailk: mailto:[email protected] http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 25 West 43rd Street New York, NY 10036 Tel: +1 212 642-4937 Fax: +1 212 840-2298 E-mail: [email protected] |
The authors of the Reference Model presented their work to date, and received feedback from the WG3 members at the meeting.
The authors of the Standard Application Model presented their work, and the contents of their list of issues were then discussed. The outcome can be found below.
Should all types be called classes, all classes types, or should both terms be used? Which terms should be used where?
The following considerations were raised by the meeting:
The meeting concluded that the term "type" should be chosen, and that the term "class" should be reserved for possible future use. This raised the issue of what to do about the PSIs defined by XTM, but that issue was deferred. (See below.)
Should we have the topic.[classes] property? It means either that classness cannot be scoped, or that classness has a double representation. The question is: is scoping of classness important? Does it cause problems for implementations and applications?
The meeting concluded that while scoping of class-instance relationships was uncommon it was useful, and to remove that possibility would mean changes to the model that would have undesirable side-effects for merging. It would also mean an undesirable break with backwards compatibility.
Based on this conclusion it was decided that the SAM should represent class-instance relationships using associations, and that the [classes] property on classes should be removed.
Should the UML diagrams be made normative?
The meeting decided that the UML diagrams should be made informative. The rationale was that a double representation using both information item specifications and UML diagrams meant risking inconsistencies between the two. Keeping only one as normative would resolve these. Also, the UML diagrams, if normative, might carry with them UML-related baggage that would be undesirable.
Do the 'linktrav' and 'listtrav' attributes of the HyTM syntax have model significance?
It was observed that these attributes were in HyTime only meant as suggestions for rendering, and so were not constraints. It was agreed that most likely the attributes would not be very useful, but that anyone who took the trouble of entering them in a HyTM document would most likely have wanted them to be retained.
The resolution was to use published subjects to retain this information. This was preferred, as it avoided having to modify the model in order to preserve the information.
The "association-traversal" issue is a duplicate of this issue.
The "topic-naming-constraint" issue was discussed, but the meeting found itself unable to resolve it. It was observed that removing the TNC would mean a break with backwards compatibility. It was further observed that a possible solution might be to switch the positions of base names and display names, but this was not accepted.
It was agreed to revisit this issue at the next face-to-face meeting of WG3.
The "prop-schema" issues was discussed, and the meeting discovered that its description in N0299 was inaccurate. Its description was therefore modified. Further, the underlying requirement was formulated as "After merging TMs that have constraints, it should be possible, for any given topic item, base name item, variant name item, and information resource used as an occurrence, to find the constraints that apply to it and where they came from. This applies only to the constraints that are part of the definition of the assertion type."
Two possible resolutions were suggested:
The "op-sorting" issue was discussed, and it was observed that different published subjects used in variant name scopes might have different sorting algorithms associated with them. Based on this observation, a number of possible resolutions were proposed:
Discussions at the meeting raised a number of new issues, which are described below.
Should base name items be merged, so that assertions made about one base name will also apply to all other base names that have the same identity? (This also applies to occurrences.)
Should it be possible to create topics that represent strings, and for it to be formally clear that these topics do represent particular strings? If so, how?
The scope of ISO 13250 is currently restricted to only defining the issues related to the interchange of topic map information. Should that scope be extended so that the standard can also cover application-internal issues?
Should the subject identifiers defined by XTM 1.0 be retained as they are, or should new equivalent ones be defined to replace the originals?
Where should the indicators for the subjects published in the new ISO 13250 be published?
Should it become possible for the scopes of topic characteristic assignments to have internal structure?
Does the use of an element type derived from "topic" in a HyTM document imply a class-instance relationship? Does use of the mnemonic attributes imply such a relationship?
How are facets represented in the SAM?
How should values from infinite subject spaces be represented in topic maps?
The authors of N0298 were instructed to prepare a more formal and complete draft of the Reference Model for the consideration of the committee.
The authors of N0299 were instructed to continue their work on the Standard Application Model, and prepare a new draft for the next meeting of WG3.
Lars Marius Garshol was instructed to prepare a more extensive draft of the roadmap (N0278) for the consideration of the committee, as it was recognized that the existing roadmap does not serve its purpose as documentation of the goals of the topic maps process for outsiders to the committee. The intention is that this document will develop into a part 0 of the standard that explains its structure.
The next meeting of WG3 will be held in Montreal, in conjunction with the Extreme Markup 2002 conference.