iso-standards | Customize | Filter | Export | Statistics | Vizigate

Description

Type(s): Occurrence type

Subject Identifiers (1)

Internal Occurrences (2)

Occurrences of this Type (57)

  • '''Warning:''' The ISO directives are very difficult to read, so this could easily be wrong. Corrections are welcome. This is the main stage in which works in done on standards, known as Commitee Draft, as standards in this stage are not yet considered stable, and can still change substantially. Hence standards tend to spend most of their development in this stage. ISO refers to this as Stage 3, CD under Consideration. Standards in this stage are referred to as Committee Drafts. A standard needs to go to FDIS at the latest three years after the initial CD has been issued. The ballot period is minimum 3 months, and at most 6 months. Successive CDs are issued as work progresses, until the decision is made that one of the CDs should be the final CD, at which point it is made an FCD. It is then balloted as an FCD. (CD)
  • A formal mathematical model that is simpler, lower-level, and makes fewer ontological commitments than TMDM. Used as the mathematical foundation for TMQL. The basis of this is the mapping from the TMDM into TMRM, which is part of this standard (as annex B). Issues here relate to the mapping, since the TMRM itself is stable. <tolog> using iso for i"http://psi.ontopia.net/iso/" select $ISSUE, $STATE from iso:issue-with(%topic% : iso:standard, $ISSUE : iso:issue), iso:issue-state($ISSUE : iso:issue, $STATE : iso:state) order by $STATE, $ISSUE? </tolog> (TMRM)
  • A mapping from TMRM to TMDM also needs to be specified. (tmrm-map-inverse)
  • A step in the ISO standards process. (Stage)
  • All proxies which are typed (names, occurrences, ...) should have the type represented as a property inside the proxy, rather than externally. (tmrm-map-typing-of-proxies)
  • CTM has single-quoted strings and triple-quoted strings, and both can span multiple lines. Could we drop the triple-quoted strings, simplify the syntax, and avoid problems in TMQL? This would give us a simpler CTM syntax and at the same time avoid the problem in TMQL. The downside is that triple-quoted strings allow XML to be embedded in them, without having to worry about quotes around XML attributes. (ctm-long-string-syntax)
  • CTM uses "xs", as does XQuery, so TMQL should follow suit and use "xs" instead of the current "xsd". (tmql-xml-schema-prefix)
  • Clause 3.3 Ontological commitments needs to be turned into a NOTE referencing the TMDM-TMRM mapping, which really specifies this. (tmql-ontological-conventions)
  • Clause B.2 specifies special typing and subtyping proxies, but these are to be removed, since these relationships are to be represented with normal association proxies, mirroring the TMDM representation. The isa and sub relations are to be kept. sub, however, is to change its name to ako, in accordance with CTM. (tmrm-map-typing-proxies)
  • Currently the grammar does not explicitly list the operators in the 'infix-operator' and 'prefix-operator' productions. Instead, the reader must see Annex A to see which operators are specified. The rationale for this is that the operators should be defined in one place only. The rationale for listing them is that preferably things should be defined in one place only. (tmql-operators-in-grammar)
  • Does TMQL support variants? Should it? (tmql-variant-support)
  • In clause 4.3 the text about the interpretation of IRIs needs to be made more visible. (tmql-iri-reference)
  • In the current TMQL draft "undef" is used for cases where there is no value. There is also "null", which means the empty sequence. Decisions about this were made in Leipzig, but need to be verified. (tmql-undef-vs-null)
  • In the pre-Leipzig '07 draft the proxies for reified items and their reifying topics are distinct. However, conceptually these proxies represent the same subject, and should therefore be merged. This is difficult, because it changes the structure of the map, it causes difficulties for the merging-by-value that is currently used, and it affects TMQL. The possibility of using a bowtie merging rule to solve this has been raised. (tmrm-map-reified-representation)
  • In this stage the standard is balloted for approval as an international standard in a 2-month ballot in JTC1 (not in the subcommittee (SC)). If the standard passes the ballot it goes to the IS stage and is published. It's only possible to make minor corrections in this case. If it does not pass it reverts to the WD stage. (FDIS)
  • Is it possible to remove the concept of an anchor from the TMQL axes entirely by simply using postfix filters for type filtering instead? (tmql-anchor-needed)
  • Issues in this state have been decided and implemented in the specification. No further discussion or work is expected, unless the issue is reopened. (Closed)
  • It is not clear what statements are implied when statement types are subtyped. The problem seems to mainly apply to associations, because of the role types, but a decision needs to be made here. A particular concern here is that the TMQL queries in TMCL must not report the wrong cardinalities simply because of inferencing, just as they must not report missing statements simply because of subtyping. (tmrm-map-subtyping-statements)
  • Means no decision has been reached on the issue yet. (Open)
  • Means that the issue has been decided, but that the decision has not been implemented in the spec yet. (Settled)
  • Means that the issue requires further work before it can be closed. May also require discussion after investigation is finished. (Needs investigation)
  • Means the issue is waiting for another issue to be resolved before it can be resolved. (Waiting)
  • No requirements document has been published for the TMDM->TMRM mapping, but this is needed. (tmrm-map-requirements)
  • Since the built-in (previously a template) "iko" was renamed in CTM to "ako", TMQL should adopt this change. (tmql-subtyping-shorthand)
  • Some proposals have included a set of constraints which valid TMDM instances in TMRM must conform to, and it has been discussed whether or not this is actually needed. The decision from the Leipzig '07 meeting is that this is needed. (tmrm-map-constraints)
  • TMQL currently allows XML everywhere, which means queries like <pre> select $x from <html> <head> <title>XML</title> </head> <body> <p>A paragraph</p> </body> </html> </pre> The question is whether it's better to only allow it in the select/return part. The argument for allowing it everywhere is that it's one rule less, which is technically simpler. The argument for removing it is that querying XML makes no sense, and is not useful, and therefore it is conceptually simpler. (tmql-xml-everywhere)
  • TMQL does not define terms like "select", "from", and "where" as keywords anywhere, and so it is possible to use these as identifiers in queries. It is not definitively clear whether or not this will cause difficulties, but consensus seems to be that if it does not then there is no reason to change this. (tmql-reserved-keywords)
  • TMQL has the boolean literals "true" and "false", simply because CTM had them at one point. Their semantics are somewhat confusing, and there is no compelling reason why they should be in TMQL. Therefore, there is agreement that they should be removed from TMQL, since they have already been removed from CTM. (tmql-boolean-literals)
  • TMQL lacks a not equals operator. The question is, should there be one? The rationale for leaving it out is that the semantics are thought to be counter-intuitive. (tmql-not-equals-operator)
  • TMQL needs to add escape sequences to its string literal syntax. This must be aligned with CTM, which already has these. There is a need to support both 4-digit and 8-digit Unicode escapes. (tmql-string-escapes)
  • TMQL needs to be able to traverse hierarchies. The question is how this should be supported. One option is to have a traversal function. Another is to have a transitive closure operation in the language. Questions: * do we want to be able to require at least one step? * do we want to be able to control whether the start node is included? * do we want to be able to say repeat 1..3 times (instead of arbitrary)? LMG to write up requirements and a proposal by November 12. (tmql-transitive-closure)
  • TMQL needs to specify the exact syntax of the CTM embedded in TMQL for creating Topic Maps data. Bare identifiers are also here interpreted using the default prefix. (tmql-embedded-ctm)
  • TMQL needs to specify the syntax of date, time, and datetime literals. Waiting for CTM to specify these, and will then reference CTM. (tmql-datetime-syntax)
  • TMQL only has an axis for going from reifier to reified, but no operation for going the other way. Is this needed? (tmql-reifier-reverse-axis)
  • TMQL should use the same syntax for subject locators and subject identifiers that CTM uses. (tmql-iri-identifier-syntax)
  • TMQL specifies some functions which need access to the whole tuple sequence (as opposed to a single tuple in the sequence) in order to do their work. "concat" is one example of such a function. It needs to be investigated to what extent this actually works in the current spec. (tmql-vertical-functions)
  • TMQL uses the wildcard '*' to mean 'any type' (or really tm:subject). Some feel that this is inconsistent of CTM's use of '*' for nameless new topics. It may be that TMQL could get by with only the '_' wildcard, and that also having '*' is not really necessary. (tmql-subject-wildcard)
  • The CTM fragment in the latest draft (pre Leipzig '07) is to be retained, but updated with the following changes: * "topic-name" should be just "name", * "topicmap" is a kind of "subject", * "variant" is a kind of "statement", * it must be updated to the latest CTM draft. All of these changes must be incorporated in the next draft. (tmrm-map-ctm-fragment)
  • The TMQL standard needs to support a default prefix used to interpret bare identifiers (like "foo"). It also needs to start supporting ~iri as a reference via an item identifier. (tmql-item-references)
  • The current TMQL draft does not specify the serialized form of Topic Maps fragments returned as XTM. That is, the exact markup produced is not specified, nor is the shape of the Topic Maps fragments. That is, given the query <pre> for $p in //person return <persons> {$p} </persons> </pre> it is not clear what goes inside the persons element. For example, should there be a topicMaps element? And what is included about each topic, and topics referenced from that topic? (tmql-xtm-fragment-output)
  • The current TMQL draft has a single shortcut for reification, ~~>, which goes from reified to reifier. Is this the best syntax? Is the shortcut needed at all? Should there also be a shortcut for the reverse operation? (tmql-reifier-shortcuts)
  • The definition of datatypes must also include an ordering of the value space. (tmrm-map-datatype-ordering)
  • The environmental clause specified in clause 6.3 of the current draft needs to be replaced with the prefix declaration syntax from CTM. (tmql-environmental-clause)
  • The interaction of the mapping with scope is still not properly understood. There are no scoping operators, and the typing relations do not respect scope. This needs to be considered carefully. (tmrm-map-scope-interaction)
  • The interpretation of IRIs in TMQL queries is ambiguous because of how the grammar is written. This problem needs to be solved. In addition, the syntax for IRIs needs to be clarified. In Leipzig it was decided to change it, but Lars Heuer had good arguments for why this was wrong. (tmql-iri-ambiguity)
  • The notation used to specify the TMQL syntax must be aligned with that used for CTM. It's OK for the TMQL notation to extend that of CTM, but they cannot be in conflict. (tmql-syntax-conventions)
  • The precedence of operators needs to be clearly defined in the standard. (tmql-operator-precedence)
  • The proxy representing the topic map should be a single proxy just stating the type of the proxy. (tmrm-map-tm-proxy)
  • The question of how inferred information shows up in the mapping, and how this affects querying, is very complex and needs to be considered more thoroughly. One wants to query with and without inferred information, and the difficulty is to see exactly what is needed, and how to achieve this. For example, given the following CTM topic map: <pre> a isa b . b ako c . </pre> This implies a third association (a isa c) which is not actually present in the topic map. It's clear that a TMQL query for all topics of type c should return a. What is not clear is whether a TMQL query counting the associations a has should return 1 (a isa b) or 2 (a isa b, a isa c)? Some requirements have been identified: * It must be possible to query with and without inferred information. * It must be possible to see from the query text which is the case for a particular query. One possibility, discussed in Leipzig, is to use the import declaration in TMQL to import one of two environments (with or without inferencing). The environment with inferencing must be the default. The next step is to identify a more complete set of requirements, and to write a strawman proposal. (tmrm-map-inferred-information)
  • The semantics of the predefined functions listed in Annex A must be defined explicitly. (tmql-define-functions)
  • This is a topic map wiki listing issues in the ISO standards currently being developed by ISO SC34 WG3. At the moment it only hosts issues for the standards Lars Marius Garshol is an editor of. This may change with time. (iso-standards)
  • This is what is known as a Final Committee Draft. Ideally, only a single FCD should be issued, and if the FCD ballot passes the standard then moves on to the FDIS stage. The ballot period is minimum 4 months, and at most 6 months. (FCD)
  • This list of issues is being prepared for the ISO meeting in Kyoto in early December. The goal is to have as many of them as possible settled by then, or at least thoroughly discussed. <tolog> using iso for i"http://psi.ontopia.net/iso/" select $ISSUE, $STATE from iso:issue-with(%topic% : iso:standard, $ISSUE : iso:issue), iso:issue-state($ISSUE : iso:issue, $STATE : iso:state) order by $STATE, $ISSUE? </tolog> (TMQL)
  • This stage, International Standard, is for finished standards which are published. These standards do not change, except at the five-year review, and for error corrections. Technical corrigenda can also be issued. (IS)
  • This stage, Working Draft, is for standards in the early stages of development. (WD)
  • This standard is not maintained by me, so although there are some issues listed here, please do not consider this list official. These are just issues I have given an identifier because there are TMQL issues that depend on them. <tolog> using iso for i"http://psi.ontopia.net/iso/" select $ISSUE, $STATE from iso:issue-with(%topic% : iso:standard, $ISSUE : iso:issue), iso:issue-state($ISSUE : iso:issue, $STATE : iso:state) order by $STATE, $ISSUE? </tolog> (CTM)
  • Triple quotes are used by TMQL to indicate CTM content, but CTM itself uses triple quotes for long strings. This needs to be aligned, but it may be that CTM is what should change. Waiting for the CTM issue to be settled. (tmql-tm-content-wrapper)

Scoped Occurrences (4)

 
Object id: 12
Item identifier(s):
[file:/home/webadmin/ontopia.net/oks-online-demo/apache-tomcat/webapps/omnigator/WEB-INF/topicmaps/iso-standards.xtm#id9]