ISO/IEC JTC 1/SC 34




ISO/IEC JTC 1/SC 34                                                   

Document Description and Processing Languages                         





ISO/IEC JTC 1/SC34 N 48                 



DATE:  1999-03-08     



REPLACES                                     



DOC TYPE:

National Body Contribution                                            



TITLE:

US National Body Comments on SC 34 N 7, ISO/IEC WD 13240, Revised Text

of ISMID                                                              



SOURCE:

US National Body                                                      



PROJECT:  1.34.43          



STATUS:

For review and discussion at the 20-22 April 1999 SC 34/WG 3 Meeting. 



ACTION ID:  ACT 



DUE DATE:            



DISTRIBUTION:  P and L Members                                             

               SC Chairman                                                 

               WG Conveners and Secretariats                               





MEDIUM:  E



DISKETTE NO.:            



NO. OF PAGES:  21        





ISO/IEC JTC 1/SC 34, American National Standards Institute, 11 West   

42nd Street, New York, NY  10036, Tel:  +1 212 642 4976, Fax:  +1 212 

840 2298, Email:  [email protected]

NCITS Document 98-D-0043

U.S. National Body Response to ISMID (SC34 N007) Request for Comments

FIXME: incorporate those comments from Martin that we agree with. Also talk to Geoff about how he wants to handle Martin's comments as a UK submission.

Comments

1.General Comments:

1.Element and attlist declarations should be presented in the style developed for 10744:1997 2.All the element forms need to be explicitly derived from the appropriate HyTime form, normally (if not exclusively) HyBrid. 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. 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. 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. 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.

2.Document Standards

"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" 3.Document Standards

"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." 4.Document Standards

"things like font"

change "like" to "such as" 5.Definition of Scope

"e.g., SGML, AVI, and WAV)"

Include CGI, MPEG, and/or other relevant ISO standard media formats to this list. 6.The example ISMID application

"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". 7.A conforming ISMID document shall:

"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). 8.Definitions

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.

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. 9.static document

"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.

10.Notation

"the ISO/IEC 10744:1997, HyTime"

delete "the" 11.The ISMID HyTime support declarations

Provide the PI form of use declaration as an alternative to the notation-based form. (As enabled by amendment 1 to 10744:1997) 12.The ISMID HyTime support declarations

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 can 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. 13.Control Flow

"Control flow shall allow construction of if, while, and switch."

Add " constructs" to end of sentence. 14.Location addressing

Update list to include listloc, proploc, nmsploc, and mixedloc.

decide whether or not relloc should be included 15.Create a Content Object

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.

<!attlist CreateContentObject

SemanticContent

CDATA -- Reference --

#IMPLIED

anchrole

CDATA

#FIXED "container SemanticContent #LIST"

anchcstr

CDATA

#FIXED "self cond" -- Not a link of 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"

#REQUIRED

Label

CDATA

#IMPLIED

HyTime

NAME

#FIXED "hylink"

Modify Content Object

Use same hylink attributes as for CreateContentObject. 16.Execute external process

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. 17.Abstract IADD Subset

Clarify the purpose of this section, e.g., by providing an introductory paragraph. 18.Abstract IADD Subset

<!Notation AIS PUBLIC "ISO/IEC XXXX:XXXX//NOTATION ISMID Application Definition Document//EN">

<!Entity % AIS public "-//DTD ISMID Application Defintion Document//EN" ndata AIS>

%AIS;

Note also that "defintion" is misspelled.

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. 19.Document Type Definition

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. 20.Informative Annex B: Sample ISMID Application Definition Document, Document Type Definition

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. 21.Annex C. Sample ISMID Instance

Complete the instance.