Topic Map Specifications | Filter | Export | Statistics | Query

Resolution

[No name] (1)

  • Resolution

Topics (100)

 

Subject Identifiers (1)

Occurrences of this Type (100)

  • 1.1. (xtm-version)
  • A [prop-schema] property on the topic map item is not needed, nor any similar properties on the topic map items that might be constrained by a schema. (prop-schema)
  • A topic may have the same locator as both subject identifier and subject address. (merge-same-subj-ind-addr)
  • A value is required for at least one of these properties. (topic-identity-required)
  • A version attribute should be added to the topicMap element. If an XTM processor finds an XTM document in a version it does not support that is an error. (xtm-topicmap-version)
  • Add a note stating that using subject identifiers not referring to information resources is bad practice. (term-subject-indicator-def)
  • Add the parent property as a computed property. (prop-parent)
  • Adding new notations will require changes to syntax specifications, therefore, this issue is not a problem. Close and let it be. (prop-notation-interp)
  • All ID attributes in XTM 1.0 should be retained. (xtm-unused-ids)
  • All errors must be reported in processing of a topic map, but a time when the report must be made is not given. In a note the standard must say that specifications building in this one will determine when such errors are reported. (err-constraint-violations)
  • Allow the same locator to be both a source locator and a subject identifier for the same topic. (merge-srcloc-vs-subjid)
  • An equality comparison will be defined for use in the conformance definition. (op-topic-map-compare)
  • Arbitrary XML markup is allowed inside the resourceData and baseNameString elements, and it must be preserved by XTM processors. (xtm-resourcedata-markup)
  • Both [role playing topic] and [role type] must have a non-null value. When deserializing XTM documents the processor must supply topics with no property values to fill the properties if the role player or role type are undefined in the XTM document. (assoc-role-player-type)
  • Can be resolved by saying display name is needed in order to have non-textual display for topics. Means we will keep the PSI and it is not simply for backwards compatibility. 5.3 remove last sentence of second paragraph, extend what is now the last sentence: "...in context which are indicated by additional parameters on the variant name." (psi-display-name)
  • Change the property name to 'subject addresses' and make it a set. (prop-subj-address-values)
  • Continue to use "equality". (term-equal)
  • Create new subject identifiers under the topicmaps.org domain. The domain will be owned by ISUG. A published subject set containing the PSIs defined in the SAM will be defined there, following the OASIS PubSubj TC guidelines. (psi-topicmaps.org)
  • Current text is fine, but must require normalization form C, because of the resolution of op-sorting. (string-normalization)
  • Define sorting order as being Unicode code point order. (op-sorting)
  • Do not add any additional features to support this. (strings-as-subjects)
  • Don't distinguish between such properties. (container-props)
  • Don't have to preserve source locators for interchange. (prop-srcloc-interchange)
  • Fragment identifiers are required on the URI. (xtm-topicref-fragment)
  • Full XPointer references are disallowed on all elements. (xtm-href-xpointer)
  • It is an error. Processing is required to stop. (xtm-reference-non-xtm)
  • It was resolved that this was a non-issue. (names-as-subjects)
  • It's OK for the property to be computed. (prop-reifier-computed)
  • Items are required to be reachable from the topic map item. (item-parent-required)
  • Keep the content model as it is. (xtm-subjectidentity-children)
  • Leave the name as 'value'. (prop-value)
  • Let subject definition in the SAM stay as it is in 3.4. Not making an explicit reference to RDF. (subject-vs-resource)
  • No explicit rules for these situations should be added to the SAM, because the [type] property and the type-instance PSI represent different relationship types. (reification-effects)
  • No extra language needed. (merge-use-of-schemas)
  • No precise definition should be given. The subject is the information resource, but what that means is not elaborated on. (term-subject-address-def)
  • No, current definition is sufficient. (term-application)
  • No, keep the element type as it is. (xtm-parameters-deprecate)
  • No, keep the element type as it is. (xtm-variantname-deprecate)
  • Normalization requirement is: String equivalency and nothing more. Put in a note to encourage better practice. (locator-normalization)
  • References from a topicRef element are handled the same way as references to non-existent topics. (xtm-external-ref-failure)
  • Remove the following from section 3.4: 'Applications and users are therefore free to merge topics as they see fit. Most commonly this will be done by inferring the subject of the topics from their characteristics.' In section 1, explain that the standard is about interchange only, and does not constrain what changes may be made to topic maps after they have been deserialized. (subject-identity-establish)
  • Scope should continue to just be a flat set of topic items. (prop-scope-structure)
  • Since the TNC is now optional there is no need to change the definition. (term-base-name-def)
  • Take examples out and put in note (to avoid reliance on examples as limitation) Use Plato's example of the good as part of the note. (term-subject-def)
  • Text as it stands sufficient, defer to Unicode for bidi issues. (string-bidi)
  • The #FIXED attributes will be declared as optional, but with specific required values, if given. (xtm-fixed-attributes)
  • The PSIs are to be published in the topicmaps.org domain. (psi-publishing)
  • The PSIs as defined in 13250 do not allow subclass loops, as they define a 'strict order'. Detection of loops is not required. Add a note saying that those wishing to use a superclass-subclass relationship with 'order' semantics can use the OWL subclass property URI. (psi-subclassing-loops)
  • The RELAX-NG schema is the normative schema. (xtm-normative-schema)
  • The SAM should not necessarily attempt to mirror the constraints implied by the XTM 1.0 DTD. (xtm-implicit-constraints)
  • The SAM should not attempt to address this. (infinite-subject-spaces)
  • The SAM should not define operations and, the specification of merging should be re-written to a more declarative style. If declarative formulation is found to be hard to understand, we may keep algorithm in an explanatory note. (op-modifications)
  • The SAM should not discuss this issue, but leave it for the PubSubj TC to define the correct practice. The PSI set as published should follow that practice. There should be no normative reference to the PubSubj RC recommendations, but there should be informative ones. The top page should be the identifier for the set independent of version, but there should also be one PSI for each version. (psi-set-psi)
  • The SAM should represent class-instance relationships using associations, and the [classes] property on classes should be removed. (prop-classes)
  • The UML diagrams should be made informative (meta-uml-normative)
  • The base name/variant name model is an improvement on the HyTM model, and that in the case of HyTM topname elements containing multiple basename elements multiple topic names should be created, each repeating the display and sort names of the topname. (variant-in-basename)
  • The empty string is allowed; null is not. (prop-value-null)
  • The id of a member element only becomes a source locator if that member element only has a single player. If it has more than one player the id is ignored. (xtm-member-id)
  • The information should be captured using published subject associations and reification. (association-traversal)
  • The name should be 'subject locator'. (prop-subject-addresses)
  • The property is needed, and should be added to the topic map item. (prop-base-locator)
  • The propery does actually contain the address of the subject, while the 'subject indicator' property contains the identifiers of the subject (as opposed to its indicators). The 'subject indicator' property is therefore renamed to 'subject identifiers'. (prop-subj-address-name)
  • The requirements for which notations to support are left to the syntaxes. The SAM will only define the notations needed by syntaxes officially part of the standard. (locator-notation-support)
  • The resourceRef element should be allowed within roleSpec, scope, and parameters. In general the syntax should avoid attempting to enforce semantic constraints. (xtm-where-resourceref)
  • The scope of a variant name should be a superset of that of the base name. (prop-variant-scope-superset)
  • The source locators of subordinate topic maps merged into a master topic map should not be retained. (merge-prop-srclocs)
  • The term "type" should be chosen; the term "class" reserved for possible future use. (type-vs-class)
  • The term 'subject address' correlates well with the term 'subject identifier', which means that this issue was really a misunderstanding. (term-subject-address)
  • The term 'topic name' should be kept, and used for the base name and its variants. The base name item in the SAM should be called the 'topic name item', since it carries the base name and its variants. (term-topic-name)
  • The term is not needed, and will be dropped. (term-subject-identity)
  • The term is not needed, and will be dropped. (term-theme)
  • The thing reified by a topic does not count as a characteristic of the topic. Standard stands as is. (term-topic-characteristic-reified)
  • The topic naming constraint should be removed, but a new published subject for defining name types that must be unique should be added. This allows controlled merging by name. (topic-naming-constraint)
  • The xlink:actuate attribute should be left out of this version of XTM. (xtm-xlink-actuate)
  • The xml:base attribute should only be allowed in the topicMaps element. (xtm-xmlbase-everywhere)
  • These published subjects are of no practical utility, and are therefore not retained in the SAM. (psi-generics)
  • This constraint has been removed, and so this issue is no longer relevant. (constr-single-subject-address)
  • This default type is not considered to be of any practical utility, and it is therefore not retained in the SAM. Applications that wish to use these published subjects may still do so. (xtm-def-occurrence-type)
  • This definition causes no difficulties as long as the conformance section is correctly phrased. (term-tm-processor)
  • This is not an error, instead it is treated as a reference to a non-existent topic. (xtm-topicref-notatopic)
  • This issue is outside the scope of the SAM, and so nothing is done about this issue in the SAM. (psi-identification)
  • This term needs no definition. (term-empty-set)
  • This term needs no definition. (term-empty-string)
  • Topic characteristic assignments are statements about the subject, not the topic. (term-topic-characteristic-assignment)
  • Topic items should not have a reifier property. (Consistent with reification in general, see term-subject-address-def for further discussion.) Definition of reification needs to be revisited in 3.4.4. (prop-reifier-topic)
  • Topic names should have type. (names-with-types)
  • Topics representing information resources are allowed as scoping topics. (prop-subj-address-scope)
  • Topics representing information resources are allowed as types. (prop-subj-address-class)
  • Two topic items that reify the same topic must merge. (reifier-merging)
  • Use the Fielding position. The locator references an ineffable identity. (locator-reference)
  • Use the name 'type' until a need for differentiating the names is found. (prop-type-properties)
  • We don't ignore unknown elements. (xtm-unknown-elements)
  • Whatever the merits or demerits of this proposal it goes beyond 'restatement of ISO 13250', and variants on occurrences should not be added to this version of 13250. (occurrence-variants)
  • When encountering a mergeMap only load the external topic map if that topic map has not been loaded before with the same set of added themes. For each XTM document, topicRef elements pointing to external documents for which there is no mergeMap reference in the same XTM document are considered to imply a mergeMap reference to that external document with no added themes. (xtm-mergemap-and-topicref)
  • Whitespace is forbidden in URIs unless it is escaped. (xtm-href-whitespace)
  • XTM 1.1 uses the same namespace URI as XTM 1.0. Note that this is only acceptable so long as XTM 1.1 is backwards compatible with version 1.0. (xtm-namespace-uri)
  • XTM processors are required to do namespace processing. (xtm-namespace-support)
  • XTM should follow RFC 2396. (xtm-same-doc-refs)
  • Yes, a disambiguating fragment reference is required in this case. (xtm-mergemap-reference)
  • Yes, the schemas should declare this attribute to be of type URI. (xtm-schema-uri)
  
Object id: 26
Item identifier(s):
[file:/apps/ontopia.net/tomcat/ontopia-5.3.0/topicmaps/tm-standards.xtm#resolution]
(C) Copyright 2001-2011 Ontopia. Some rights reserved.