Occurrences of this Type (115)
-
According to XTM 1.0 the default occurrence type is the
"occurrence" published subject. Should this standard follow its lead?
If so, what does it mean? (xtm-def-occurrence-type)
-
Are all information items in a data model instance required to be
reachable from the topic map item by traversing the properties and
items? (item-parent-required)
-
Are subtype loops allowed? (psi-subclassing-loops)
-
Are topic characteristic assignments statements about the topics's
subject, or about the topic? (term-topic-characteristic-assignment)
-
Are topics representing information resources allowed as types? (prop-subj-address-class)
-
Are topics representing resources allowed as themes in scopes? (prop-subj-address-scope)
-
At what level of interpretation does the topic represent the
resource? Does it represent that storage location? The stream of
bytes? The stream of bytes interpreted in some particular way? The
standard must either leave the details open or clarify this. Note that
it may be impossible to clarify when the interpretation of locators
is left undefined. (term-subject-address-def)
-
Attributes declared as #FIXED in the DTD can not be guaranteed to
always be present in the XML document as parsed, either because there
is no DOCTYPE declaration, or because the parser does not read the
DTD. This affects both namespace and XLink parsing, which again
affects the procedure used to recognize element types. (xtm-fixed-attributes)
-
Distinguish between properties which have containment semantics,
and those which are references? (container-props)
-
Do the 'linktrav' and 'listtrav' attributes of the HyTM syntax have
model significance? (association-traversal)
-
Do the definitions of the terms 'topic map processor' and 'topic
map applications' have unwanted consequences for what software
architectures can be conforming implementations of this standard? (term-tm-processor)
-
Do we need to define the term 'application' formally? (term-application)
-
Do we need to define what the empty set is? And the empty string? (term-empty-set)
-
Do we need to define what the empty string is? What about non-empty
string (used liberally throughout)? (term-empty-string)
-
Does XTM allow full XPointer references, or only bare names? (xtm-href-xpointer)
-
Does the thing reified by a topic count as a characteristic of the
topic? It is the subject of the topic, so the question is perhaps
whether we are interested in the characteristics of topics or
subjects. (term-topic-characteristic-reified)
-
Does this standard need to define how sorting of topics is done? It
is a highly fundamental operation. On the other hand, users may want
flexibility in this regard. (op-sorting)
-
For full internationalization it is necessary to support
bidirectional text in names and occurrences. This requires that
certain kinds of information be provided about the text. (string-bidi)
-
How are references from a topic map to elements which have no
corresponding information item in the model interpreted? When they
occur as occurrences, subject indicators, subject addresses or
similar? (xtm-unused-ids-interpretation)
-
How does one determine which subjects are published subjects and
which are not? Is it necessary for the SAM model to provide a
mechanism for this at all? (psi-identification)
-
How does one uniquely identify the set of published subjects
defined in SAM? Is there a need to do so? Is a published subject for
these published subjects needed? (Does it include itself?) (psi-set-psi)
-
How should XML data be represented in the data model? (xml-data-representation)
-
How should the unconstrained scope be represented? (scope-unconstrained-rep)
-
How should values from infinite subject spaces be represented in topic
maps? (infinite-subject-spaces)
-
ISO 13250 states that subject identity may be "inferred from the
topic's characteristics." Does SAM need words to the same effect? (subject-identity-establish)
-
ISO 13250:2000 allows a display name to have a scope that is a
subset of that of the corresponding base name. This apparent
contradiction needs to be resolved. (prop-variant-scope-superset)
-
ISO 13250:2000 does not restrict display/sort names to a single
base name, by design. Is it acceptable for SAM to do so? (variant-in-basename)
-
If a locator syntax allows equivalent locators to be given
different syntactical expressions normalization must be applied in
order to take this into account. Where should the text that sets out
this requirement go? Does it belong in this document, or in the syntax
specifications? (locator-normalization)
-
If it may not be null, why may it be empty? (prop-value-null)
-
If the subject identifier is a locator that does not refer to an
information resource, what is the subject indicator then? This also
applies to the subject address. (term-subject-indicator-def)
-
If the topic naming constraint is not retained by the standard, is
there then any need for this published subject? Or will the base name
then take over the function previously fulfilled by this published
subject? (psi-display-name)
-
If you reify a topic name, does that affect your allowed type?
If you reify an association, must you inherit its type? (reification-effects)
-
Is [label] a better name? (prop-value)
-
Is a base locator property on the topic map item needed by other
specifications? (prop-base-locator)
-
Is it acceptable for the [reified] property to be computed, or must
it be a fundamental property? (prop-reifier-computed)
-
Is it acceptable that constraint violations may be reported at any
time? (err-constraint-violations)
-
Is it allowed for a topic to have the same locator item both as
subject identifier and as subject address? If it does, must not this
mean that the topic has two subjects? (merge-same-subj-ind-addr)
-
Is it an error for a topicRef element to refer to an
element that is not a topic element? (xtm-topicref-notatopic)
-
Is it an error if a mergeMap element refers to an XML
document that contains multiple topicMap elements without
providing a disambiguating fragment reference? (xtm-mergemap-reference)
-
Is it likely that the term "IRI" will replace "URI" in the
foreseeable future? Does there need to be well-defined mechanism for
adding new possible values for the [notation] property? (prop-notation-interp)
-
Is the URI given in the xlink:href attribute (of
topicRef elements) required to have a fragment
identifier? (xtm-topicref-fragment)
-
Is the term "subject identity" needed? It is defined in XTM 1.0,
but it is not clear that there is any use for it. The XTM 1.0
definition is: That which makes two subjects identical, or
distinguishes one subject from another. (term-subject-identity)
-
Is the term 'theme' useful, or best forgotten? (term-theme)
-
Is this conformant to the XML c14n with respect to namespaces? (cxtm-namespace)
-
Is topic.[subject address] the right name for the property? We have
[subject indicator], not [subject identifier], so why [subject
address] rather than [subject resource]? (prop-subj-address-name)
-
Is whitespace allowed in the xlink:href attribute? If it
is allowed, how is it interpreted? If it is not allowed, what action
is taken when it is found? (xtm-href-whitespace)
-
Must both [role playing topic] and [role type] have values? (assoc-role-player-type)
-
Must locators really refer to information resources? Some URN
schemes allow resources that are not information resources to be
addressed. This affects the definitions of "information resource",
"locator", as well as the [subject identifiers] and [subject
addresses] properties. (locator-reference)
-
None of the interchange syntaxes allow source locators to be
interchanged. Is interchange of source locators a desired feature? Do
the syntaxes need to be extended to accomodate source locators? (prop-srcloc-interchange)
-
RFC 2396, section 4.2, specifies that URI references of the form ""
and "#fragment" are resolved relative to the URI of the current
entity. Should XTM should follow this? (xtm-same-doc-refs)
-
Should HyTM mnemonics be represented in the model using special
properties, or should they be represented using already existing
constructs? (mnemonic-representation)
-
Should all or some element types which have xlink:href
attributes also be given an xlink:actuate attribute? If so,
what should the legal range of values be? (xtm-xlink-actuate)
-
Should all types be called classes, all classes types, or should
both terms be used? Which terms should be used where? (type-vs-class)
-
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.) (names-as-subjects)
-
Should base names be allowed to have both types and scopes in the
same way that occurrences do? (names-with-types)
-
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? (strings-as-subjects)
-
Should it become possible for the scopes of topic characteristic
assignments to have internal structure? (prop-scope-structure)
-
Should multiple resourceRef elements be allowed inside
subjectIdentity? (xtm-subjectidentity-children)
-
Should occurrences be allowed to have variants in the same way that
topic names are? (occurrence-variants)
-
Should resourceRef be allowed in roleSpec,
instanceOf and parameters? (xtm-where-resourceref)
-
Should source locators of B be copied into A? If they are, it is
implied that A is the same topic map as B, which is not true. Also,
topics reifying B will then also reify A, which means that any
statements made about B will also apply to A. (merge-prop-srclocs)
-
Should the "topic", "association", and "occurrence" PSIs be
specified in the SAM? If so, what do they mean, and what is their
function? (psi-generics)
-
Should the DM have a conformance section of its own? If so, what
does it mean to conform to the DM? (sam-conformance)
-
Should the UML diagrams be made normative? (meta-uml-normative)
-
Should the XSDL and RELAX-NG schemas declare xlink:href
attributes to be of type URI? (xtm-schema-uri)
-
Should the [subject addresses] property be called [subject
locators] instead? (prop-subject-addresses)
-
Should the [value] property be normalized? Note: This issue also applies
to occurrence items. (cxtm-resource-data-normalization)
-
Should the id attribute of member be ignored?
This makes it impossible to reify association roles in XTM. On the
other hand, member elements do not necessarily map to a
single association role item. (xtm-member-id)
-
Should the parameters element type be deprecated and
replaced by scope? (xtm-parameters-deprecate)
-
Should the specification have a non-normative section providing
guidance for implementors on how to do reserialization properly? (xtm-reserialization-recommendation)
-
Should the standard retain the topic naming constraint? (topic-naming-constraint)
-
Should the standard say as little as possible about the nature of
subjects, or should it be more detailed in order to provide guidance
to readers? The current text is detailed, but may be too much so. (term-subject-def)
-
Should the standard state outright that "subject" and "resource"
(as per RFC 2396) are the same thing? (Quote: A resource can be
anything that has identity. Familiar examples include an electronic
document, an image, a service (e.g., "today's weather report for Los
Angeles"), and a collection of other resources. Not all resources are
network "retrievable"; e.g., human beings, corporations, and bound
books in a library can also be considered resources.) (subject-vs-resource)
-
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? (psi-topicmaps.org)
-
Should the topicMap element have a version attribute? (xtm-topicmap-version)
-
Should the variantName element type be deprecated, and the
content model of variant be adjusted to make it redundant? (xtm-variantname-deprecate)
-
Should the version number in the XTM namespace URI be changed? (xtm-namespace-uri)
-
Should the xml:base attribute be allowed on every
non-empty element type? (xtm-xmlbase-everywhere)
-
Should there be a computed [parent] property on all information
item types except the topic map item type? (prop-parent)
-
Should this property only accept a single value? (prop-subj-address-values)
-
Should topic items be required to have a value for at least one of
the [source locators], [subject indicators], or [subject locator]
properties? (topic-identity-required)
-
Should topic items have a [reifier] property? Should it be possible
to reify topics? If so, how? (prop-reifier-topic)
-
Should topic map items have a [schema] property that may contain
their schema definition(s)? This would make it clear where to find the
topic map schema. On the other hand, the TMCL specification should
perhaps have its own rules for specifying how to find the schema of a
topic map. It may be better to keep the levels strictly apart. (prop-schema)
-
Should we always output an ID attribute, or only when the topic map is
reified? (cxtm-topicmap-id)
-
Should we define an equality criterion for topic map items? There
is no need for duplicate removal for topic maps, but on the other hand
that would be what is needed to define the conformance requirements on
serialization implementations. (op-topic-map-compare)
-
Should we define operations that describe how modification of SAM
instances is done? (op-modifications)
-
Should we extend the content model of resourceData to
allow arbitrary markup within the element, and require implementations
to be able to represent this? (xtm-resourcedata-markup)
-
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? (prop-classes)
-
Should we name the type properties [association type], [role type],
and [occurrence type], or should they all be called [type]? (prop-type-properties)
-
Should we retain the id attribute on element types which
do not represent something that can be reified? (xtm-unused-ids)
-
Should we speak about 'equality' of items, or 'equivalence'? (term-equal)
-
The XTM DTD contains a number of implicit constraints, such as that
an addressable subject may not be used as a theme or a type. Should
these constraints be mirrored in the SAM? (xtm-implicit-constraints)
-
The definitions of 'base name' and basename.[value] are too naïve
in the presence of the TNC. If we are to have the TNC they must
change. (term-base-name-def)
-
The presence of a TMCL schema may allow applications to improve the
result of merging topics/topic maps by providing enough information to
allow implementations to do additional transformations and redundancy
removal. How should the SAM specification deal with this
possibility? (merge-use-of-schemas)
-
The purpose of this topic map is to document
the topic map standards process, and thereby make it easier to follow
and easier to understand its result and the rationale for that
result. The topic map is entirely unofficial. (Topic Map Specifications)
-
The rules for ordering association role items in section are not sufficient to make comparisons of
[role played] properties in all cases. (cxtm-topic-roles-played-order)
-
The scope of ISO 13250 is currently restricted to only defining the
issues related to the interchange of topic maps. Should that scope be
extended so that the standard can also cover application-internal
issues? (scope-extension)
-
The term "subject address" does not correlate with the term
"subject indicator", since "subject address" corresponds more clearly
to "subject identifier". A better name should be found. (term-subject-address)
-
The text as specified here requires that XTM processors do XML
Namespace processing. Is that acceptable? XTM 1.0 seems to imply that
namespace processing is optional. Also, proper namespace processing
allows the use of different namespace prefixes, which break straight
DTD validation. (xtm-namespace-support)
-
The text as written implies that processors must use a Unicode
normalization form, without requiring any particular one. The Web
Character Model requires Normalization Form C, as does the current XML
1.1 Working Draft. Requiring normalization improves string comparison,
but imposes a possibly unwelcome burden on implementors. (string-normalization)
-
This definition of scope is different from that of XTM 1.0 and ISO
13250:2000, in that it explicitly says topic characteristic
assignments are valid for each of the subjects in its scope
individually. Is that acceptable? (term-scope-def)
-
Unknown elements are ignored in order to ensure forwards
compatibility, but this means DTD compliance cannot be required.
Which is more important? (xtm-unknown-elements)
-
What does it mean when type-instance associations are scoped? How
is this to be interpreted, and what is the interaction with scoped
supertype-subtype associations? (psi-type-instance-scope)
-
What happens if a resource that is not an XTM document is
referenced with mergeMap or topicRef? (xtm-reference-non-xtm)
-
What happens if two different topic items reify the same item?
Should they be merged? (reifier-merging)
-
What happens when external references from an XTM document fails?
Note that only topicRef and mergeMap references can fail, since these
are the only references followed by an XTM processor. (xtm-external-ref-failure)
-
What happens when the same locator appears as a source locator for
one topic and as a subject identifier for another? Does that locator
then become a source locator or a subject identifier of the merged
topic? This question arises both under deserialization and under
merging. (merge-srcloc-vs-subjid)
-
What happens when the single subject address constraint is violated? (constr-single-subject-address)
-
What if the topicRef element refers to a topic in an
external resource where the topicMap element is not the document
element. Is that an error? What if there is more than one topicMap
element? (xtm-topicref-xtmwrap)
-
What is the correct behaviour if a topicRef to an external
document occurs first, followed by a mergeMap with added
themes? (xtm-mergemap-and-topicref)
-
What locator notations, if any, must be supported? (locator-notation-support)
-
What version number should we give the updated XTM syntax? (xtm-version)
-
Where should the indicators for the subjects published in the new ISO
13250 be published? (psi-publishing)
-
Which schema should be the normative schema? (xtm-normative-schema)
-
XTM 1.0 has a term "topic name", but it is not clear how it relates
to the term "base name". Its use in XTM 1.0 seems to be inconsistent.
Is the term useful, or should it be abandoned? (term-topic-name)
|
