[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:	DOCUMENT T1.0
Notice:	New notesfile (DOCUMENT.NOTE) now available (see note 897)
Moderator:	CLOSET::ADLER

Created:	Mon Feb 09 1987
Last Modified:	Thu Oct 31 1991
Last Successful Update:	Fri Jun 06 1997
Number of topics:	897
Total number of notes:	4397

859.0. "directory names in angle brackets" by VAXUUM::KOHLBRENNER () Fri Aug 28 1987 13:01

VAX DOCUMENT V1.0 has difficulty handling the directory part of a
file specification when it is enclosed in angle brackets, rather than
square brackets.  Thus, 

  NODEXX:DEVICEYY:<USERNAME>FILENAME.TYP

will generally result in a warning message stating that <USERNAME> 
is an undefined tag.

This can be a problem in two different situations:

  1. if the angle brackets are used in the DOCUMENT command,
     or if they have been used when defining logical names that
     may be used in accessing SDML files that are to be read by
     DOCUMENT.  In this case, the tag translator may pass the
     file specification around internally and may attempt to
     evaluate the bracketed name as a tag.  The only work-around
     for this case is to avoid using the angle bracket version of
     the file specification.  This problem is a high priority item
     for the v1.1 release of DOCUMENT.

  2. in examples in the SDML file.  In this case, the writer must
     avoid using the angle bracketed form of the file
     specification, or must prevent the interpretation of the angle-
     bracketed text as a tag invocation.  This can be done with the
     <literal> tag, but it is a nuisance.  The string shown above
     would have to be coded as one of the following: 

      NODEXX:DEVICEYY:<literal>(<USERNAME>)FILENAME.TYP
      NODEXX:DEVICEYY:<literal>(<)USERNAME>FILENAME.TYP

     An easier solution is to define a tag with a short name that
     can be used to represent a literal left angle bracket.  Then the
     left angle bracket can be coded using this tag.  It still
     requires an action on the part of the writer, but the action is
     less onerous.  Suppose we define the tag <lab> to stand
     for a literal Left Angle Bracket.  Then the file spec is coded as:

      NODEXX:DEVICEYY:<lab>USERNAME>FILENAME.TYP

     To define the <lab> tag, insert the following line at the front
     of your symbols file (the file that you normally reference with a
     /SYMBOLS qualifier).    

<define>(lab\|<literal>(<)&\0\0\\\|<literal>(<)&)

bill

T.R	Title	User	Personal Name	Date	Lines
859.1		VNASWS::GEROLD	You're my favourite waste of time !	`Mon Aug 31 1987 07:56`	7
	I got bitten by that, too. The source of all evil was in the SYSUAF.DAT, where the directory was specified as <dir>. So as a quick workaround change it there. Actually I think there should be things higher on the priority list. Gerold
859.2	Glad to hear about V1.1 enhancement	STAR::GUISSO	Ridendo dicere severum	`Tue Sep 01 1987 04:36`	10
	I'm glad to hear that V1.1 will address the problem. My files have many angle-bracketed directory specs. Any coding "workaround" that requires the writer to define a complex macro is really unacceptable. In the meantime, I'll just use angle brackets for directory specs, as my tech reviewers require, and I'll notify my editor to expect appropriate "undefined tag" error messages in my bookbuild log files. I refuse to pollute my source files with spurious tags, because I don't want to confuse the next writer/maintainer. Lazarus
859.3	when is a <rose> not a <rose> tag?	VAXUUM::KOHLBRENNER		`Thu Sep 03 1987 13:03`	33
	The improvement/fix that will come for v1.1 will address the problem of being able to supply file specifications that use angle brackets for the directory part of the file specification. That is what I defined as problem 1. Thus, you will be able to specify a file spec on the DOCUMENT command, or in the argument to an <INCLUDE> tag that has an angle-bracketed directory name. There is no fix/improvement coming for a file specification that you supply as text in your SDML file. The SDML language will continue to use < and > to surround tagnames. Thus any angle- bracketed sequence of characters that meets the rules for a name gets recognized as a tagname and gets diagnosed as undefined if it is not a tag. There is simply no way for DOCUMENT to determine that the <TABLE> 'tag' in the following example is not a tag: <code_-example> NODEXX::DEVICE:<TABLE>FILENAME.TYP;5 <endcode_example> We may define an easier way to write <literal>(<), so that you do not have to define your own "complex tag" to do it, but you will have to do something to avoid having the tag translator see <table> as a tag. There is a limit of 30 warning messages after which the tag translator notifies DOCUMENT not to proceed to the next step in processing. So letting all those directory names that look like tags go through with warning messages may prevent processing past the tag translation step. bill
859.4	How about <<TAG>>	EAYV05::WESTON	Telecomms, the key to Tomorrow	`Fri Sep 04 1987 12:16`	11
	As a suggestion, how about looking at the use of double angle brackets to tell the tag translator that the element is not a tag and the content, including the one pair of brackets is a literal? For example, <<TEXT>> is equivalent to <literal><TEXT><endliteral> This has the logic of treating "<" as an escape character which is negated by the immediately following "<" and vice versa at the termination. This is similar to the DLE character in comms protocols John