Re: Comments on 8 December AUGL

responses to responses to ...

look for PJ and CMN

On Mon, 13 Dec 1999 pjenkins@us.ibm.com wrote:

  
  Issue 3) Ckpt 3.3 add "prepackaged" and s to descriptions
  PJ: partly agree.  I think we still need the word "automatically", but I
  agree with Ian that "place-holder" is not well defined. So, I prefer Ian's
  re-wording with "automatically" added back in as such:
  
  Checkpoint 3.4 Do not automatically generate equivalent alternatives. Do
  not reuse previously authored alternatives without author confirmation.
  Note: For example, prompt the user for a text equivalent of an image. If
  the author has already provided a text equivalent for the same image used
  in another document, offer to reuse that equivalent and prompt the author
  for confirmation. Refer also to checkpoints 3.3 and 3.5.
  
CMN I could live with this - it does seem to clarify significantly.
  
PJ  
  Issue 6) delete "that is stylistic" from Checkpoint 4.5
  PJ: Either way, we need to define the terms "presentation markup" and
  "structural markup" and give examples of such markup [we don't currently in
  either the glossary nor the techniques].
  
CMN I agree that we should define these. A suggestion:

Presentation markup
  Language used to provide a suggested presentation or layout for content,
for example CSS, markup used to control fonts or positioning. Presentation
markup can be used to suggest presentation for particular structure elements.

Structural markup
  Language used to identify the structural role of elements in a
document. For example, headings, sections, memebers of a list, components of
a complex image or diagram can be idntified using markup. Often used with
presentation markup which suggests a particular rendering.
  
PJ  Issue 7) Checkpoint 5.1
  PJ: the three terms are all the same to me, functions, features, or
  functionalities. But adding "user interface" is limiting.  I read the
  current wording to be more than just the natural integration into the user
  interface of the tool, but also into the way the tool works inside, or the
  plumbing (non UI) components of the tool.
  
CMN I read it the same way, which is why I support using User interface - it
is not important to the end user how the tool is built (except as a product
differentiation - a well-built tool is generally more efficient than a
badly-built one), only how the user interface works.

Charles

Received on Monday, 13 December 1999 20:36:34 UTC