| TITLE: | Disposition of Comments on ISMID WD |
| SOURCE: | Norman Chenard and David Cooper, editor |
| PROJECT: | JTC1.34.43 |
| PROJECT EDITOR: | Norman Chenard and David Cooper |
| STATUS: | Editors' report |
| ACTION: | For information |
| DATE: | 20 April 1999 |
| DISTRIBUTION: | SC34 and Liaisons |
| REFER TO: | |
| REPLY TO: | Dr. James David Mason
(ISO/IEC JTC1/SC34 Chaiman) Lockheed Martin Energy Systems Information Management Services 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov http://www.ornl.gov/sgml/wg4/ ftp://ftp.ornl.gov/pub/sgml/wg4/ |
1. Scope as defined
The scope of ISMID is described in a fairly distributed fashion over the `introduction' and `scope' sections of N007. The key points are (quotes from N007):
oa standard for representing the behavior within documents in an unambiguous way for the purpose of interchange among heterogeneous interactive document development and delivery systems.
oWhile there are established standards for implementing Graphical User Interface objects in a programming context, there is a need for a standard that will allow developers of interactive documents to express in a device independent manner how they intended to make use of those interface objects. ISMID provides an architecture for defining how the interface objects communicate with the structured content covered by existing standards.
oThis International Standard, known as the Interchange Standard for Modifiable Interactive Documents or ISMID, facilitates the interchange of Modifiable Interactive Documents (MIDs) among heterogeneous interactive document development and delivery systems by providing the architecture from which common interchange languages can be created. ISMID is a client architecture of International Standard ISO/IEC10744:1997, Information technology -- Hypermedia/Time-based Structuring Language (HyTime) and is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language
The intended field of application is concisely described:
oThe field of application of ISMID is Electronic Performance Support Systems (EPSS), computer-based interactive document systems that provide users access to just-in-time information and on-the-job training. Two common types of EPSS are Interactive Electronic Technical Manuals (IETMs) and Interactive Courseware (ICW).
The provision of interactive behaviour for an electronic document can happen in several ways. Amongst these, it is possible to see three kinds of interactivity from a user perspective, with different kinds of expected user interaction:
1.Hyperlinking, as already supported by ISO 10744 HyTime
2.Displaying an interactive document within the windows of a WIMP GUI, with the characteristic interface elements of this kind of GUI (eg buttons) providing interactive behaviour
3.Direct user interaction with formatted/displayed elements of a document, i.e. interaction functionality (associated with eg displayed glyphs, paragraphs, diagram annotations) which uses the displayed document as a detailed map into underlying product data &/or instructional information, with associated behaviour/functionality such as diagnostic tests of equipment, or recording assessment performance.
It is clear that (3) is a desired eventual aim, and that this level of support is a genuine requirement to fulfil industry requirements for IETM and instructional systems. (Evidence for this has been gathered from conversations with UK experts, and also from published documents from two domains: CALS, and the Instructional Management Systems project). It is equally clear that it will be some time before all the issues surrounding (3) are sufficiently well worked out to support the detailed drafting of appropriate supporting standard(s).
These issues include the detailed outcome of currently planned work on industry requirements, and detailed models, for STEP/SGML harmonization.
The current ISMID draft is, in its technical detail, clearly aimed at (2). It corresponds well to a current industry need for standardized data interchange at this level, in support of currently accepted functionality for IETM (eg as described in the European aircraft industry consortium specification AECMA S1000D, chapter 4.4.2, and in the US DoD IETM spec MIL-PRF-87268A).
In addition, the exact relationsips between the various concepts, semantics, and element forms specified in the draft, are not easy to work out - even for a reader already familiar with interactive documents. The clarity and accessibility of the draft, as well as its completeness, needs to be improved.
1. All substantive provisions of the standard should be in parts of its content, not in annexes
Accepted. Moved the "ISMID Application Definition Document (IADD)" from Annex to clause within the standard body.
2. The Scope and Field of Application of ISMID should be amended to show that it is intended to apply specifically to information interchange supporting document presentation within EPSS in a particular way: that is, displaying document content within the windows of a generic WIMP-type GUI, with the characteristic interface elements of this kind of GUI (eg buttons) providing interactive behaviour
The ISMID architecture is not limited to any specific GUI environment - in fact, it need not define a GUI at all. The architecture defines a language for defining any stimuli that a system could receive, including stimuli that are not received through a GUI. The responses also may be something other than rendering information to the uesr through a GUI. An object derived from the CreateControl element form need not be a GUI widget; it could be a means of communicating with an external system.
For example, the object may be a "EnviromentMonitor" control that montitors the temperature in a climate sensative environment. In this case the stimulus may be that the temperature has exceeded 40 degrees. The response to this stimulus may be that the system shuts down equimpent that should not be run when the temperature exceeds 40 degrees.
3. It should be clearly stated that other aspects of interactive document behaviour are not covered by this standard: (that hyperlinking is supported by HyTime; and) that direct user interaction with formatted/displayed elements of a document - in particular, interaction functionality which uses the displayed document as a detailed map into underlying product data - is the subject of possible future standardization in co-ordination with ISO 10303 STEP
The editors have revised the ISMID architecture to allow parameters to be associated with stimuli. This added capability will enable coordination of ISMID behavior with the behavior of any outside process.
4. The purpose and application (in the target domains of interactive manuals and instructional support) of the conditional behaviour, and other features, supported by ISMID, should be made clear, to give all users of the standard access to the rationale for its detailed provisions
Explanation will be given with example implementations where possible. The possible implementations are too broad for a comprehensive treatment of all features that could be defined in ISMID applications.
5. An information model (prepared using the EXPRESS language of ISO 10303 part 11) should be prepared, as a substantive part of the standard, to specify unambiguously the intended interrelationships between information objects, interface objects, displayed content, behaviours, elements of the ISMID abstract architecture, and elements of the IADD. This work should interface appropriately with the information modelling of SGML and HyTIme currently in hand in STEP/SGML harmmonization activities. (This comment addresses in a general way many of the detailed queries raised below.
If this is a requirement, we may need the assistance of an EXPRESS language expert.
I am not sure that an ISMID system should be made to "declare the ISMID applications it supports". I particularly see this as a problem in systems designed for use in military and other security conscious environments.
We envision industries defining ISMID applications for which ISMID systems must be created. For example the MOD, DoD, and ATA may each define an ISMID application. A software vendor may decide to create a system that will support the MOD and ATA applications but will not support the DoD application. For cases like this, the editors felt that there should be a requirement for the vendors to formally declare which applications they support. This may not be necessary, we may want to leave it up to the buyer to determine whether or not the system supports his/her application.
This will make it difficult for people to take an existing application with a set of applications declared by the originator and then come up with a new application for it: unless they have the right to modify the DTD they apparently cannot do this, do references to an existing application that consist of a DOCTYPE statement with a PUBLIC identifier will be problematical
Accepted. This requirement has been removed. The document must declare the application to which it conforms through the DOCTYPE declaration as is the case with any SGML document.
I do not see why a conforming ISMID application needs to be "limited to the HyTime modules and options specified in the ISMID HyTime support declaration". I can see a situation where the ISMID application contains a general-purpose HyTime engine that supports all facilities, but for a particular application only a subset of these functions are required. The application should define the minimum set of required functions that tools supporting the application need to have to maximise the chances of that application being moved to other platforms. The standard should not require the supporting tool to being limited to supporting these functions. The requirement that a conforming ISMID document shall "not exceed the feature set declared for any system that will operate on the document" is also incorrect. It is not up to the document to determine whether it suits all systems that want to use it: it is the responsibility of the system to check it can provide the minimum se t of functionality requested in the ISMID Hytime support declaration.
Accepted. Modified conformance clause to address this comment.
The requirement that conforming systems must support either HyFunk or the DSSSL expression language is not reflected in the section on The ISMID HyTime Support Declarations, which requires support for HyFunk and has no option for the support of the DSSSL expresssion language. (The standard needs to define its own extension to the support declarations to show which option is required to be used.)
Modified Clause "The ISMID expression language" to specify that HyFunk must be supported by a conforming ISMID system and that support for the DSSSL expression language is optional.
Modified the Clause "Conformance" to reflect the change.
Modified the notation declaration to specify HyFunk as the default.
In the definition of a hyperdocument the undefined term web is used. The term network would seem more appropriate, though how one draws the line between information connected within the collection of information that consitutes a document and links that go outside this collection is unclear from the current definitions of these term
Accepted. Revised the definition of "hyperdocument"
Add HyTime to list
Accepted
Replace first occurrence of HyTime with "Hypermedia/Time-based Structuring Language (HyTime).
Accepted
The restriction of location addressing to the nameloc and treeloc location element forms will make it impossible to associate stimuli with entities, the properties of elements or entities, lists or co-ordinate positions. It will also prevent users from using queries that resolve to relevant addresses, and prevent the use of references to material yet to be produced in the form of bibliographic location specifications. Is this restriction really necessary? (Note from AMW - this restriction is part of my evidence for suggesting the limitation in scope above)
Accepted. Modified conformance clause to allow for location addressing mechanisms other than nameloc and treeloc. nameloc and treeloc are now the minimum required location addressing mechanisms that must be supported by a conforming ISMID system.
Add explanation of role of VariableDeclaration, Assign and Execute objects, and explain why they need to be positioned before the compulsory SystemChain if they are used.
Accepted
Removed them. This was an error. The responses in the SystemChain are executed when the system receives the OnSystemStart stimulus. Nothing can happen before the SystemChain.
The last sentence of the first paragraph (Examples of container objects are...) should be a note.
Accepted. Changed examples for all CreateXXX to notes.
The second paragraph should include a statement of the relationship of VariableDeclarations and Assign elements within containers with those in the containing MID element.
Removed VariableDeclarations and Assign elements from the MID content model. This was an error. The responses in the SystemChain are executed when the system receives the OnSystemStart stimulus. Nothing can happen before the SystemChain.
The conditions under which no stimuli would be present should be specifically explained.
Added explanation for all CreateXXX architectural forms.
Also add note warning users that any variables that require modification in a ModificationContainer definition must have been defined at the time the container was created. (Though I personally do no see why this restriction is required.)
The standard currently allows variable declaration only when the object is created, but variable values can be modified at any time. In a non-sequential presentation, the order of modify events is not necessarily predetermined. The editors recommend enforcing the declaration of all variables during create to reduce the complexity of error-checking in software.
Are there specific advantages to be gained by allowing new variables to be declared when an object is being modified?
In the third paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
If the refrange attribute requires that all references be to preceding elements, and the required parent attribute must reference "element types derived from the CreateContainer form" what can the parent attribute of the outermost container point to?
Accepted.
Modified the text to allow the outermost container's parent attribute to point to the MID element.
Added an ID attribute to the MID architectural form.
Modified text in "Modifiable Interactive Document" and "Interface Objects" to reflect this change.
The rules for ireftype suggest that parent could point to any create object element type, which could include CreateContentObject and CreateControl type elements, but the rules for parent forbid this. Is this correct?
Which rules for ireftype?
How are content objects associated with containers?
The value of the content object's parent attribute must be the value exhibited by the ID attribute of an element derived from the CreateContainer architectural form.
The model of CreateContainer allows for the creation of empty containers. Is this correct?
Yes
In the fifth paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
Again what is the purpose of an empty ModifyContainer element. A better model would be (assign+|(assign*, stimulus+))
Note: The same comment applies to the models of all other Modify element types.
The purpose of a ModifyContainer may be to modify attribute value assignments.
The rules for ireftype suggest that parent could point to any create object element type, which could include CreateContentObject and CreateControl type elements, but the rules for object forbid this. Is this correct?
Again. Which rules?
How do you modify the set of content objects associated with a container?
There are at least two ways to interpret this question:
1. How do you modify which set is associated with a container, or
2. How do you modify all of the objects associated with a container
The child elements of a container each point to the parent container to which they belong, rather than the container pointing to its (arbitrarily sized) collection of children. Therefore the objects in a container have to be modified independently; one possible modification is to change the parent container.
We added the Parent attribute to the ModifyXXX architectural forms to allow for this.
Add note explaining relationship of Assign elements in a ModifyCoontenObjects with those defined in the Global, CreateContainer and CreateContentObject elements.
Added explanation to first paragraph of each ModifyXXX architectural form.
In the second paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
The use of IDREF as the type of the parent attribute means that each object may only ever be associated with a single container. Is this necessary? What happens if the same object is to appear in two or more frames/windows/etc?
An object can have only one parent at a time. As with all attribute values that specify a property of the object, the value of the IDREF attribute can be changed at any time through a ModifyXXX element.
It sounds like you may be using the word "object" to refer to the information that will be rendered in a content object (i.e. object == bubbles.bmp). In fact, the content object is not the information but just the object used to render the information. This does not preclude rendering one piece of information in serveral different content objects simultaneously.
Add note after the paragraph describing the parent attribute to remind uses that the B in the refrange attribute's fixed value means that ContentObjects must be defined after any containers they are to be associated with.
Accepted
Add a note after the paragraph describing the ContentRef attribute to remind readers that only a restricted set of location addressing techniques can be used within ISMID.
Set of location addressing techniques is no longer restricted.
In the second paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
Surely a object attribute must refernce an element derived from CreateObject rather than CreateContainer.
Accepted Changed "CreateContainer" to "CreateContentObject".
Add a note after the paragraph describing the ContentRef attribute to remind readers that only a restricted set of location addressing techniques can be used within ISMID.
Set of location addressing techniques is no longer restricted.
Add note explaining relationship of Assign elements in a ModifyContainer object with those defined in the Global and CreateContainer elements.
Added explanation to first paragraph of each ModifyXXX architectural form.
In the second paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
The restriction on the reference range of the parent attribute requires that controls be linked only to containers that have previously been declared. Not only does this make it impossible to associate controls with objects, but also makes it difficult to define controls globally.
The restriction is that every control object must have a parent on which the control object is created. Furthermore, the parent must be created before any of its "children" are created. It is unclear what is meant by "define controls globally."
What does it mean to create a control object with no contained elements?
It means that there are no stimuli associated with the control object.
In the second paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
Add note explaining relationship of Assign elements in a ModifyControlObject element with those defined in the Global, CreateContainer and CreateControlObject elements.
Added explanation to first paragraph of each ModifyXXX architectural form.
Delete second paragraph.
Accepted
In the third (now second) paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
This element type does not appear in the model of any other element type: where does it fit in the hierarchy?
This element type has been added to the CreateObject parameter entity declaration.
In the second paragraph insert the phrase "after a separator" between "followed" and "by".
Accepted
Why are you allowed to modify the VariableDeclaration of an external object, but not an internal one?
Accepted. Should not be allowed to modify the VariableDeclaration.
Is there any reason why DestroyObject does not use refrange to ensure that the object to be destroyed has previously been created?
Accepted.
Added the refrange attribute.
What happens if a Stimulus element has no contents?
If there is also no value for the ResponseChainReference attribute, the system responds by doing nothing.
Why must a stimulus reference a ResponseChain? Are there no occasions when restarting the sequence by reference to the SystemChain might be appropriate?
The SystemChain could contain only a single "ExecuteChain" which references a ResponseChain. In this case all responses to the OnSystemStart stimuli are contained within a ResponseChain. This ResponseChain can be referenced again at any time by using "ExecuteChain".
The spelling of the element name End in this model differs from that in the model of the stimulus element. This may be significant in systems that support namecase sensitivity (which was allowed by the WebSGML amendment recently published).
Accepted.
Changed the spelling on stimulus element.
Where is the nameName element declared?
Accepted. The element type should be Name not nameName. Change has been made.
Change "the ResponseChain" to "a ResponseChain".
Accepted
Change rspchref to ResponseChainRefAccepted
Accepted
Change "expr" to "expression".
Accepted
The text of this element indicates that Break is compulsory, yet it is always optional in the model. Please explain conditions under which it can be omitted.
Accepted.
Changed the text to indicate that the break is optional.
Note that element name in declaration has an initial capital whereas all references to this element are all in lowercase. (See earlier note on WebSGML case sensitivity.)
Accepted
Change "expr" to "expression"
Accepted
Add declaration for variableType attribute or delete sentences referring to same.
Added the declaration.
Added a VariableTypes parameter entity declaration.
What is the meaning of the last sentence.
The sentence no longer applies. Deleted the sentence.
Insert space in "andstring"
Accepted
Where can the Execute element be placed?
Accepted. In the system chain or any response chain. The fix was made to the "Responses" parameter entity declaration.
The queryloc option is not listed in the HyTime support declaration so is not valid as the value of the HyTime attribute.
Accepted. Removed attribute. Changed the declaration based on a US comment.
This is out of date: the element names do not match those in the preceding text. Please check carefully.
Review and move to informative annex.
Is the ISMID Abstract Architecture actually Clause 11?
No. Will fix with auto-numbering and cross referencing.
Why is the acronym for this given aas IAS in the text rather than the AIS used as the entity name?
Accepted
The public identifier should start "ISO/IEC 1......" rather than "-".
Accepted
What is the purpose of the phrase "included in this section in its entirety"?
Deleted.
How must a conforming IAD "declare and define the semantics of each stimulus"?
The editors have added headings within the Stimuli section of the IADD to require explicit definition of both the semantics and declaration.
Indent Type entries to indicate relationship with related objects more clearly.
Accepted
Note: No comments are made on Annex B as at this stage the example is not likely to be accurate enough for checking.
Will complete Annex B (Now Annex A).
1.Element and attlist declarations should be presented in the style developed for 10744:1997
The intent is for the DTD to be XML compliant. Inline comments are not allowed in XML, so the one line per parameter convention is not allowed.
2.All the element forms need to be explicitly derived from the appropriate HyTime form, normally (if not exclusively) HyBrid.
Accepted
3.Define consistent policy for the capitalization and case of all ISMID-defined names (element types, attributes, etc.). If bicapitalization is used, remember that use of the ISMID architecture in an XML (or other NAMECASE GENERAL NO) context will require the use of that exact case in all places, including the value of fixed attributes in ISMID client documents. Recommend using all lower case with "." as word separator.
The "." separator implies an object.property relationship that we do not want to imply. Reviewed the document for consistent bicapitalization.
4.Provide normative annex providing the integrated ISMID architectural DTD. Note that this can be autogenerated using the tools developed for the HyTime standard. Contact Peter Newcomb or Eliot Kimber for details.Requested autogenerator from Peter.
5.Provide a version of the ISMID architecture that conforms to the restrictions on declarations imposed by the XML SGML declaration, if necessary (it may be the case that the general-use declarations already conform to the XML SGML declaration). In particular, the declarations must be consistent in their use and non-use of start and end tag omission parameters. For normal SGML use, they must be provided, for XML-type SGML declarations, they must be omitted.
Does this mean provide two versions of the DTD? The editors' intent is to conform to the XML SGML declaration.
6.As a matter of practice, any abstract design like ISMID should include a formal definition of its abstract data model. This should be provided either as a property set and grove construction process or as an EXPRESS data model (ISO 10303) and mapping definition. Suggest defining a property set with a graphical EXPRESS model as an illustrative adjunct.
We may need help with this.
"Standards currently exist for describing the structure, content, and formatting of static documents and hyperdocuments"
Saying that documents are static is incorrect--it is the *presentation* of the document that is static, not the document itself. The source data of a document is of course static, whether the presentation is static or dynamic. Thus, reword the sentence above to read:
"Standards currently exist for describing the structure, content, and static presentation of documents and hyperdocuments"
Accepted.
"a standard for representing the behavior within documents" change "within" to "of" then add: "The behavior definition may be embedded within the documents to which it applies."
Accepted.
"things like font" change "like" to "such as"
Accepted
"e.g., SGML, AVI, and WAV)"
Include CGI, MPEG, and/or other relevant ISO standard media formats to this list.
This list is intended to be a sample of a few notations, not an exhaustive list. We have added CGM so that we have one example for text, graphic, video, and audio.
"The example elements inherit all "
Avoid the use of "inherit" in respect to architectural derivation. "implements" or "provides" appear to be better terms. The relation between a client and base architecture is much closer to the concept of implementing interfaces rather than that of true subclassing. Suggest using one of these in place of "inherit".
Accepted
"be a valid SGML document using the DTD described in the IADD."
Correct to "be a valid SGML document conforming to the encompassing architecture described in the IADD". The general principal is that the rules for client documents are defined by encompassing architectures, which may either be local declaration sets or the base architecture of the document (in the case of a document with omitted DTD declarations).
Accepted
Add definition for "interactive document":
Interactive document
1. The presentation of a document in which the order, formatting, and content of the source information may be dynamically modified as the document is presented based on external stimuli (such as user interaction) and presentation algorithms defined within the document or within the software that governs the presentation of the document. 2. A source data collection that explicitly enables and defines the rules for its presentation as an interactive document.
NOTE xx. The source data for an interactive document need not explicitly enable or define its interactive behavior in order for it to be presented as an interactive document (in other words, all documents are potentially interactive whether or not they were originally authored with interactive presentation in mind). However, it is still useful to distinguish documents that explicitly enable and define interactive presentation from those that do not. In addition, through the use of location addressing it is possible to apply an explicitly interactive document to other documents in order to add explicit interaction definitions to them.
Accepted
This definition makes clearer the distinction between "document" in the SGML sense (a static source of data) and "document" in the rendition sense (a particular view or presentation of the source data). In particular, it is important to at least remind readers that any document can be made interactive in sense (1) through the application of behavioral style. There has long been a general misconception that normal SGML documents are somehow irretrievably static, which of course is not true. The ISMID standard should not unwittingly reinforce this misconception by its necessary focus on interaction and its direct binding to presented informative content.
It might be useful to have a paragraph or two about this distinction between document as source data and document as presentation artifact in the introduction.
Documents can be defined either as a static collection of source data or as a rendered presentation of that data. SGML enables static source data to be reused in many document presentations—ISMID is intended as a mechanism for defining rules governing the rendering of each unique document presentation.
"A document in which the order of presentation of information is predetermined by the author."
At best an author of an SGML document can intend a presentation order--they cannot predetermine it because the presentation is always under the control of style specifications. Replace the definition text with this:
static document
1. A document whose order of presentation is largely or entirely determined by the source order of the information.
2. A document authored with the intent or expectation that the presentation will be static.
NOTE xx. any static document in sense (2) can be presented as an interactive document given the necessary presentation software and behavioral definition. This behavioral definition may be provided by ISMID documents.
Accepted
"the ISO/IEC 10744:1997, HyTime"
delete "the"
Accepted
Provide the PI form of use declaration as an alternative to the notation-based form. (As enabled by amendment 1 to 10744:1997)
Where is this described?
Include listloc and proploc to the required location address forms as these are fundamental addressing forms. Add mixedloc as it is the base for nameloc. Include: loctype, valueref. Remove conloc (it's not used or usable in the architecture).
Note that as far as the current draft is concerned, there is no place where valueref or conloc is or can be used. However, one of the comments given below can be satisfied by using valueref. If this approach is used, include valueref, if not, do not include it.
Added mixedloc as base for nameloc. The editors recommend making loc types optional, but not part of the minimum support declaration.
The text in the ISMID HyTime Support Declarations section has been modified to clarify the fact that the declaration specifies a minimum set rather than a comprehensive set. This is also clarified in the ISMID Conformance section by removing the statement that an ISMID system will be limited by the declaration.
It is also possible to specify a HyTime content object to use other facilities.
Removed conloc from the ISMID HyTime support declaration.
"Control flow shall allow construction of if, while, and switch."
Add " constructs" to end of sentence.
Accepted
Update list to include listloc, proploc, nmsploc, and mixedloc.
decide whether or not relloc should be included
This will be the same as the set listed in the HyTime Support Declaration.
The CreateContentObject form needs to either be a hyperlink or the content referenced needs to be the effective value of the ContentRef attribute. I think the former would be more understandable by your audience even though the latter is probably more semantically correct. Suggest the following declaration. Note renaming of ContentRef to SemanticContent.
SemanticContent
CDATA -- Reference --
#IMPLIED
anchrole
CDATA
#FIXED "container SemanticContent #LIST"
anchcstr
CDATA
#FIXED "self cond" -- Not a link if SemanticContent not specified --
linktrav
CDATA
"A"
listtrav
CDATA
"N"
refrange
CDATA
"parent B"
ireftype
CDATA
#IMPLIED
parent
IDREF
#REQUIRED
loctype -- HyTime location type specification --
CDATA
"SemanticContent IDLOC"
ID
ID
#REQUIRED
Label
CDATA
#IMPLIED
HyTime
NAME
#FIXED "hylink"
>To reference an entity (e.g., a CGM graphic file) using this method, create a nameloc and reference it via the SemanticContent attribute.
The editors chose to implement the "more semantically correct" option because this technique is now used elsewhere in the standard for referencing the value of object property attributes.
SemanticContent IDREF #IMPLIED
valueref CDATA #Fixed "SemanticContent SemanticContent"
refrange CDATA "parent B SemanticContent B"
ireftype CDATA #IMPLIED
parent IDREF #REQUIRED
ID ID #REQUIRED
Label CDATA #IMPLIED
>
Use same hylink attributes as for CreateContentObject.
Accepted
I really don't like the design for this but I'm not sure what the right design is. It should really be done by defining the external process as an entity and then addressing the entity, either directly, or as the location source for a name-space loc where the name is the entry point within the external process. The problem is how to pass arguments. This will require additional thought before a crisp comment can be provided.
This has been reworked. Please review the new design.
Clarify the purpose of this section, e.g., by providing an introductory paragraph.
The following subset of ISMID architectural types is likely to be instantiated in conforming ISMID applications.
%AIS;
It's not clear what the intent here is. Assume that it is not to use the new (with TC2) parameter data entity feature is it? In normal SGML, parameter entities do not take notations. Clarify the intent or fix the syntax.
Moved from Annex into above section, and removed the word "Abstract" from the title to reduce confusion.
Removed notation declaration.
Removed "ndata AIS" from the parameter entity declaration.
Note also that "defintion" is misspelled.
Accepted
Correct to read "shall be governed by a valid, SGML Document Type Definition or encompassing architecture". This enables the use of DTD-less documents (SGML or XML), which requires the use of architectures.
Accepted
Change title to "Encompassing Architecture (Document Type Definition)" (or its equivalent) to make the connection back to the use of the term encompassing architecture elsewhere in the document.
Accepted
Complete the instance.
Feel that a sample instance is not necessary in the standard. Removed sample instance.
1. Previous US comments recommended an XML-conformant version of the ISMID architecture and noted in particular the implications for the start- and end-tag omission parameters of element type declarations. Note that the XML version is subject to other restrictions. One example is the use of SGML comments as separators in declarations other than comment declarations. While we had recommended following the style developed for ISO/IEC 10744:1997 in element type and attribute definition list declarations, this style calls for comments between the parameters of these declarations. Since such comments are not permitted in XML, the XML version of the architecture must place comments describing the element types and attributes outside of the declarations.
Does this mean that we need two versions of the architecture? As XML-conforming is also SGML-conforming, would it be OK to have one architecture only?
2. In the name of the Standard and the language, change "Modifiable" to "Multimedia". We make this request because the term "modifiable" is not generally used in conjunction with interactive documents, while such documents are almost invariably used in multimedia applications.
Accepted
3. ISO 8879 does not define (or even use) the term "valid SGML document". The correct phrase is "conforming SGML document".
Accepted
4. Definitions that come from other standards should identify their source (e.g. "document" is from 8879).
Accepted
5. Add (or revise as indicated) the following definitions. Change the text as needed to use these terms consistently (e.g., distinguish appropriately between "interactive document" and "interactive presentation").
interactive presentation
A form of presentation of a document in which the order of navigation through the document content is modified during presentation in response to conditions.
NOTE: The modifications are typically in response to external stimuli, such as user interactions, which is why these presentations are termed "interactive". However, the dynamic modification can also be in response to presentation algorithms contained in the document or within the system controlling the presentation.
NOTE xx. A document need not be an interactive document in order for it to be the subject of an interactive presentation.
Accepted
interactive document
A document that is not intended for static presentation. It typically contains algorithms for its own interactive presentation.
There is another US comment suggesting a change to this definition. That defintion was accepted.
static presentation
A form of presentation of a document in which the order of navigation through the document content is essentially the same as the order in which the content appears in the computer representation of the document.
NOTE xx. In a static presentation, any dynamic modification is typically limited to the navigational functionality offered by a printed volume, such as page-turning and cross-reference following.
Accepted
static document
A document that is intended for static presentation.
There is another US comment suggesting a change to this definition. That defintition was accepted. I prefer this defintion combined with the definition of "static presentation". Which do you favor?