 |
Description  |
|
|
FIELD OF INVENTION
This invention relates in general to electronic calendaring methods, and in
particular, to a calendaring method in which a calendar owner can select a
subset of entries from different calendars based on criteria that is
entered interactively by the calendar owner.
CROSS-REFERENCES TO RELATED APPLICATIONS
1. Co-pending application Ser. No. 008,039 filed concurrently herewith,
entitled "Electronic Calendaring Method to Establish Calendar Floating
Triggers for Calendared Events and Processes" and assigned to the assignee
of this application is directed to an electronic calendaring method in
which a calendar owner can selectively trigger a predefined action and
response to detecting one or more criteria related to the calendar event
that has previously been defined and entered into the system.
2. Co-pending application Ser. No. 008,249 filed concurrently herewith,
entitled "Method For Automatically Reconciling Entries on Two Copies of
Independently Maintained Electronic Calendars," and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner who keeps a detached personal copy of his
master calendar can automatically reconcile the calendar entries that have
been made on each calendar copy, independently of the other since the last
time the detached copy was made and interactively resolve calendar event
conflicts.
3. Co-pending application Ser. No. 008,038 filed concurrently herewith,
entitled "Electronic Calendaring Method Which Provides for Automatic
Assignment of Alternates In Requested Events," and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner who receives a request to participate in
a calendar event originated by another calendar owner, and currently being
calendared by that owner, can establish an automatic response which
reflects the assignment of an alternate to the event based on the
relationship of the information that accompanies the request and criteria
that the calendar owner has pre-established for each potential alternate.
4. Co-pending application Ser. No. 008,036 filed concurrently herewith,
entitled "Electronic Calendaring Method for Automatic Confirmation of
Resource Availability During Event Calendaring", and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner, when calendaring an event such as a
meeting, which requires, in addition to a meeting room, such articles as a
projector, video conferencing equipment, etc., automatically receives
confirmation that requested articles are available and reserved for the
calendared meeting event.
5. Co-pending application Ser. No. 008,033 filed concurrently herewith,
entitled "Method For Developing Automatic Automatic Replies in an
Interactive Calendaring System" and assigned to the assignee of the
present application is directed to an electronic calendaring method in
which a calendar owner can respond automatically to requests for
participation in events being calendared by another person. The nature of
the reply is based on an analysis of the parameters set forth in the
request and an algorithm employing a set of prioritized criteria that the
calendar owner has established to provide the automatic response.
BACKGROUND ART
The prior art has disclosed a number and variety of interactive electronic
calendaring systems and method. The objective of all of these systems is
primarily to assist the person who, for a number of different reasons,
maintains a calendar of future events containing various information about
the event at entry points on the calendar which relate to the time of the
event.
The increase of personal computers and intelligent workstations in recent
years has made it possible for calendar owners to establish and maintain
their calendars on these interactive type data processing systems. Hence,
the term "electronic calendaring."
Two general types of interactive electronic calendaring systems have thus
evolved in the art. In one type of calendaring system, the owner of the
calendar is generally also the user of the workstation and that
workstation is generally not a part of a larger network. Generally, in
these types of systems, the calendar functions involve presenting a screen
to the user representing a day calendar divided into a number of time
periods or time slots. Each period is capable of displaying a limited
amount of text that the user enters. In some systems, the day calendar can
scroll vertically to present more time periods to the user or horizontally
to present longer text entries. The operator can generally "page" forward
or backward and, in most arrangements, can display a requested date. These
calendaring methods generally do not limit the type of event that is
calendared nor the terminology employed at any of the entry points and, to
that extent, function in the same manner as conventional manual calendars
or appointment books. The electronic calendaring method and systems do
have an advantage over the prior art manual calendaring of events in that
the user generally has the ability to scan a time span involving a large
number of days and identify calendared events quite rapidly.
The other type of calendaring arrangement that has developed in the prior
art involves multi-user environments having a large number of terminals or
workstations which are generally part of a larger communication network.
Usually these networks have been established to permit the users to
interact with each other and with data maintained on the system. In this
environment, a user at a terminal or workstation can send a message to one
or more of the other users on the network concurrently, and is notified
when the addressees have received and read the message. In most of these
environments, each user generally maintains a calendar, and in many of
these environments the reason for having a network in which users
interact, quite often involves user interaction that requires reference to
the respective electronic calendars of the users. A considerable amount of
time is therefore spent by calendar users in many organizations, with
people checking and rearranging their calendars to accommodate various
events such as meetings and presentations. Calendar systems have
progressed to the point where a person who is calling a meeting can at
least view the calendars of a number of users that he intends to invite to
a meeting, in order to determine a common available time for the meeting.
(U.S. Pat. No. 4,626,836 is an example of such a system).
In this prior art system, a screen is presented to the meeting originator
which requests the data necessary for the system to determine times that
all potential attendees would be available. The data requested includes,
for example, the length of the meeting, a time period during which the
meeting should be conducted, the place of the meeting and the names of the
attendees. Based on this data, the method returns a screen of available
times after inspecting each attendee's day calendar during the time period
for free time slots or periods.
The originator then selects the beginning time and end time of the meeting,
including the time and date, and invitations are automatically sent to all
the attendees, requesting their attendance at the scheduled meeting.
While such an automatic system saves time in finding a convenient meeting
time, relative to the manual process, the process is limited to the
scheduling of meetings based on "free time" as represented by the absence
of a calendar entry on each of the inspected calendars. This approach does
not recognize that some calendar entries are less important than others
and, in practice, it is often impossible to find a common period of "free
time" for a meeting that involves a large group of people or a meeting
involving a number of people whose work requires a large number of
meetings.
The prior art systems are limited to examining calendars of others in
connection with setting up a meeting. It was soon recognized that there
were other situations besides calling a meeting where it would be
beneficial to be able to create a "selected view" of a number of
individual calendars.
A department manager, for example, may have an assignment that can be given
to a number of different people in his department. If the calendaring
system could display to the manager the calendared events of each of these
people which meet a set of search criteria entered into this system
interactively by the manager, considerable time and effort could be saved
by everyone involved. While time available or free time may be one of the
search criteria entered, other criteria such as the relative importance of
the events that are calendared to the new assignment, might also provide
the manager with more relevant data than just free time. Also, identifying
the person who handled the same or similar assignment in the past, similar
assignments scheduled in the future or other assignments scheduled at the
same geographic location or customer could be important criteria for the
manager to employ. These deficiencies of the prior art electronic
calendaring methods, namely using only free time to find relevant calendar
entries, are overcome by the present invention.
SUMMARY OF THE INVENTION
In accordance with the present invention, an electronic calendaring method
is provided in which a calendar owner can request the system to display or
print out a selected subset of calendar entries from a plurality of
calendars maintained by the electronic calendaring system. The method
assists the calendar owner in defining the selected subset by presenting
to him a "view select" screen containing various prompts to which he
responds by keying in the search criteria that he wishes to employ, to
determine if a calendar entry belongs to the subset. The subset is then
displayed in one or more composite screens. Since criteria other than free
time may be employed in defining the selected subset, the "view select"
function can be used separately or to provide enhancements to other
electronic calendaring functions such as the automatic scheduling of
meetings.
It is therefore an object of the present invention to provide an improved
electronic calendaring method.
A further object of the present invention is to provide an electronic
calendaring method in which a subset of calendar entries from more than
one electronic calendar can be automatically selected.
A still further object of the present invention is to provide an improved
electronic calendaring method in which a calendar owner can request a
composite display of selected calendar entries from a plurality of
electronic calendars, which entries are selected based on interactively
entered search criteria other than free time.
Another object of the present invention is to provide an electronic
calendaring method in which a calendar owner is assisted in defining to
the system, search criteria based on an assignment of priorities to
calendar entries to be used by the system in selecting calendar entries
from different calendars maintained by the system for a subsequent
concurrent display to the calendar owner.
Objects and advantages other than those mentioned above will become
apparent from the following description when read in connection with the
drawing.
DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an interactive workstation in which the method of the
present invention may be advantageously employed.
FIG. 2 illustrates a network of interactive workstations of the type shown
in FIG. 1.
FIGS. 3a-3c illustrate screens which are employed by the users in
calendaring an event.
FIGS. 4a and 4b are screens presented to the calendar owner to assist in
defining criteria to be used by the system in selecting calendar entries
during the view select function.
FIGS. 5a and 5b is a flow chart, illustrating the detailed steps of the
method of the present invention.
BRIEF DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 illustrates the functional components of an interactive type data
processing terminal on which the electronic calendaring method of the
present invention may be advantageously employed. The terminal comprises a
processing unit 11 which includes a microprocessor block 12, a
semiconductor memory 13, and a control block 14 which functions to control
input/output operations in addition to the interaction between the
micro-processor block 12 and the memory unit 13.
The terminal further includes a group of conventional peripheral units
including a display device 16, a keyboard 17, a printer 18, a disk storage
unit 19, and a modem 20. Since the details of the above-described
functional blocks form no part of the present invention and can be found
in the prior art, only a brief functional description of each block is set
forth, along with a description of their interactions, sufficient to
provide a person of ordinary skill in the art with a basis of
understanding applicants' improved electronic calendaring method.
Processing unit 11 corresponds to the "system unit" of a personal computer
system such as the IBM XT or IBM AT type systems. Unit 11 is provided with
an operating system program which may be one of the many versions of DOS
(Disk Operating System) which is normally employed to run the systems. The
operating system program is stored in memory 13 along with one or more
application programs that the user has selected to run. Depending on the
capacity of memory 13 and the size of the application programs, portions
of these programs, as needed, may be transferred to memory 13 from the
disk storage unit 19 which may include, for example, a 30 megabyte hard
disk drive and a diskette drive. The basic function of the disk storage
unit is to store programs and data that are employed by the system and
which may readily be transferred to the memory unit 13 when needed. The
function of the diskette drive is to provide a removable storage function
for entering programs and data into the system, and a vehicle for storing
data in a form that is readily transportable for use on other terminals or
systems.
Display device 16 and keyboard 17 together provide for the interactive
nature of the terminal, in that in normal operation, the interpretation
that the system gives to a specific keystroke by the operator depends, in
substantially all situations, on what is being displayed to the operator
at that point in time.
In some situations, the operator, by entering commands into the system,
causes the system to perform a certain function. In other situations, the
system requests the entry of certain data, generally by displaying a
prompt type of menu/message screen. The depth of the interaction between
the operator and the system varies by the type of operating system and the
application program, but is a necessary characteristic of terminals on
which the method of the present invention may be employed.
The terminal shown in FIG. 1 further includes a printer 18, which functions
to provide hard copy output of data developed or stored in the terminal.
Lastly, the modem 20 functions to transfer data from the terminal of FIG.
1 to a host system through one or more communication links which may be a
commercial type link or a dedicated communication link.
FIG. 2 illustrates a network 21 of interactive type workstations of the
type shown in FIG. 1. As illustrated, the network includes a plurality of
terminals which are interconnected with each other and to a host central
processing unit 23, which in turn is connected via communication link 24
to a second host processing unit 25, which also connects to another
network 26 of interactive workstations. Functionally, the system operates
to allow one terminal to communicate to one or more other terminals using
established communication protocols, so that the various serially
connected communication links are transparent to the operator. Such
systems are well known in the art, and are currently in extensive
commercial use. Since these communication links per se are not part of the
present invention, only those details that are necessary for an
understanding of the calendaring method of the present invention will be
described. It should therefore be assumed in the following description,
that each workstation on the network has a system node address and a "post
office" address, and that to simplify the description, there is only one
individual assigned to each node on the network. It should further be
assumed that conventional communication services are provided by the
system, such as directory listing of individual calendar owners and
shareable resources such as meeting rooms, etc., which require scheduling.
The system shown in FIG. 2 processes information as various types of data
objects such as text data objects, graphic data objects, and calendar data
objects. Each of these data objects are represented by a datastream which
comprises a series of structured fields.
A calendar object datastream has the following sequence of structures.
______________________________________
Begin Document (BDT)
Begin Page (BPG)
Begin Calendar Data (BCL)
Calendar Data Descriptor (CDD) (Optional)
Calendar Data SF (CAD)
Calendar Structures (COCA)
End Calendar Data (ECL)
End Page (EPG)
End Document (EDT)
______________________________________
The format of the datastream for other type data objects contain the begin
document, begin page, end page, and end document data structures.
Structured fields corresponding to those listed above for a calendar
object are also employed for other type objects.
A structured field is a self-describing entity which contains related
groupings of parameter values and triplets. The structure field, as shown
below, has two parts: the Structured Field Introducer and the Structured
Field Content.
##STR1##
The structured field begins with a Structured Field Introducer. The syntax
and semantics of the Structured Field Introducer are defined by the
architecture which governs the datastream in which the structured field is
found. The Structured Field Introducer contains as the first two bytes a
parameter which defines the length of the structured field. It also
contains an identification code which uniquely identifies the structured
field.
The Structure Content portion of each structured field contains structures
and triplets, which give the structured field its meaning. Parameters in
the triplets define the attributes of the Calendar Object. Every parameter
has a value either explicitly appearing in a triplet, inherited from a
control structure in the datastream's hierarchy, or implicitly defined as
a default. This default may also be the alternate action value.
Every structure is either required or optional. A required structure
appears in the object because the function of that structure is required
and for proper performance of the function an value is necessary.
An optional structure need not appear in the object either because the
function of that structure is not required or because the function is
required, but default values are acceptable for all parameters.
As shown above, a calendar data (CAD) structured field (SF) precedes the
actual calendar data. A calendar data descriptor (CDD) SF can precede the
CAD SF to provide formatting information for the data that follows.
Calendar data comprises named data structures and named triplets which are
composed of parameters. A parameter is a variable to which a value is
assigned. Parameters can be optional or required. Parameters are also
classified as terminal or non-terminal. A terminal parameter is merely the
last parameter in a string of parameters.
A parameter can have one of three types of values assigned.
1. NUM--This is a number or a numerical value.
2. COD--This is a code assigned a specific meaning.
3. BST--This is a bit string of binary elements, each of which is usually
independent of the other.
In the following discussion it will be assumed that a byte comprises 8 bit
positions numbered 0-7 from left to right, with position 0 being the high
order position. Bit position 0 represents 2.sup.** 7 (2 to the 7th power),
while bit 7 represents 2.sup.** 0 (2 to the 0 power).
The various calender structured fields and calendar triplets are defined by
the following type of table.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
n-m name type v x www
______________________________________
In the figure:
BYTES refers to the position, indexed on zero.
NAME is the name by which reference is made to the parameter.
TYPE denotes the syntax of the parameter by "type," The architected types
NUM, COD, and BST were described earlier.
LGTH denotes the length of the field in terms of the exact number of bytes
or the maximum number of bytes permitted.
OPT refers to the optionality of the parameter's appearance in the
structure or triplet:
O means that the parameter is optional.
R means that the parameter's appearance is required.
If a required parameter is missing, an exception condition exist. The
alternate action is to ignore the structure, self-defining field, or
triplet to which the missing parameter belongs.
Syntactically descriptive material below the figure indicates what
additional restrictions apply to the structure or triplet defined by the
figure.
Calendar structures and calendar triplets which are relevant to the present
invention will be described using the above-described format. After the
structures are described, the display screens that are presented to
calendar owners by the system in order to solicit information when a
calendar owner wants to perform a calendaring function will be described.
A flow chart setting forth the detailed steps of the method of the present
invention will then be described in connection with the program listing of
pseudocode that will assist persons skilled in programming interactive
terminals to implement the method of the present invention.
Since the view select function operates to select the subset of calendar
entries from one or more calendars, it is necessary to describe in detail
the data structures that are employed by the system in the process of an
owner calendaring an event on his calendar. In the preferred embodiment,
calendar entries are classified into a number of different types. Since
the system contemplates interchanging calendar data throughout the system,
including terminals that are remotely connected, such as those shown in
FIG. 2, entry types and presentation language are controlled by a defined
architecture. While the same display screen may be employed to solicit the
data for a number of different event types, the data structures and
triplets, required or optional, will vary by event type.
While some of the structures to be described and the triplets associated
with these structures are not directly involved in the view select
function, they have been described in order to provide background for the
reader and a basis for a comprehensive understanding of the claimed
process and its relationship to the processes described and claimed in the
cross-referenced application.
The various calendar object data structures to be described are preceded by
a calendar data structure shown below.
__________________________________________________________________________
CALENDAR DATA (CAD) STRUCTURE FIELD (SF)
BYTES
NAME TYPE
MIN MAX LGTH
OPT
__________________________________________________________________________
0-1 Structured Field Length
NUM 8 32767
2 R
2 Structured Field Type1
COD X`D3`
X`D3`
1 R
3 Structured Field Type2
COD X`EE`
X`EE`
1 R
4 Structured Field Type3
COD X`5B`
X`5B`
1 R
5 Flags BST 0 0 1 R
6-7 Segment Sequence Number
NUM 0 32767
2 R
8-7+n
Calendar Data * * n R
__________________________________________________________________________
*Values depend on the Calendar Object structure and triplet specification
The calendar Data SF (CAD) identifies the data as calendar data and
specifies the length of the calendar data. The calendar Data SF contains,
for example, up to 32767 bytes of calendar structures and calendar
triplets (called "Calendar Data"). Calendar data varies with the function
employed by the generator of the object.
MAJOR CALENDAR STRUCTURES DESCRIPTION
This section describes the major structures that are involved in the
present invention. The structures consist of a mixture of calendar
triplets. The triplets are described in the Calendar Triplets Description
section that follows this section.
The calendar structures are preceded by the Calendar Data structured field
(CAD). Parameter values specified by the system can be overridden by
parameters specified in calendar data. For example, the Code Page of
Symbols for Displaying and Printing Data.
In the structure description, bits are consecutively numbered from left to
right starting with zero.
The format for all of the structures is the same. The format is shown
below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 LENGTH NUM R
2-3 TYPE COD R
4-n TRPLT1 to R
TRPLTn
______________________________________
where
LENGTH=A two-byte value of the number of bytes in this structure including
byte zero.
TYPE=A two-byte binary number that designates a specific structure
function.
TRPLT1 TO TRPLTn=Calendar Structure Triplets.
The length of structures can vary depending on the number of triplets
included.
If the length excludes all or part of an optional parameter in a triplet,
then the value for that parameter and any parameters that follow are not
changed; that is, the LENGTH field is used as specified.
If a structure is invalid or unsupported, an exception is raised. If the
length field excludes a required parameter or triplet, an exception is
raised. If a structure contains an invalid or unsupported parameter or
triplet, an exception is raised.
MEETING (MTG) STRUCTURE
The meeting structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure
NUM * 32767 2 R
Length
2 Structure
COD X`D3` X`D3` 1 R
Type1
3 Structure
COD X`85` X`85` 1 R
Type2
4-3+n
Meeting * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The MTG structure provides the fields necessary to interchange meeting
information, the scheduling of meetings and requests for meeting
information. It also provides a specific search classification to allow
building a composite calendar for a specified list of calendar owners.
The Valid MTG Triplets are listed below and defined in detail in the
following section.
ERROR ACTION (EAC)--An EAC triplet may occur in any sequence and is
optional.
STRUCTURE ID (SID)--The SID specifies the ID for the meeting. optional SID
may be included to identify a Trigger (TRG) associated with the meeting.
DATE AND TIME (DTT)--The DTT triplet provides the meeting time(s) and
date(s) and is required. DTT triplets must occur in ascending time(s) and
date(s). A meeting that occurs at non-sequential times can be scheduled by
using more than one DTT triplet specifying the required times.
NAME (NME)--Network Address (NAD), Postal Addresses (PAD) and User Status
(UST) triplets may be used to provide user status and addresses for a
named item. NME triplets and associated NAD, PAD and UST triplets may be
included for both the CALLER (meeting owner) and the ARRANGER (meeting
arranger). The Name Status byte specifies whether or not NAD, PAD and UST
triplets follow the Name triplet which is optional.
USER STATUS (UST)--The UST triplet provides the role and status for the
person named in the NME triplet. This triplet is only valid when it
follows a NME triplet and is optional.
NETWORK ADDRESS (NAD)--The NAD triplet provides the network address for the
person named in the NME triplet and is optional.
POSTAL ADDRESS (PAD)--The PAD triplet provides the the mailing address for
the person named in the NME triplet and is optional.
EVENT STATUS (EVS)--The EVS specifies the meeting status and is optional.
TIME STAMP (TMS)--Only one TMS triplet is allowed in the MTG structure and
it is optional.
ENTRY SECURITY (ESL)--If this control is omitted the security level is
PUBLIC. Only one ESL triplet is allowed in the MTG structure and it is
optional.
SET CODED GRAPHIC CHARACTER SET GLOBAL ID (SCG)--The SCG selects the
character set and code page for characters contained in the triplets that
follow the SCG in the calendart structure. The Network Address character
set and code page are not affected by the SCG. The active code page is
restored automatically at the end of the calendar structure.
SUBJECT (SBJ)--The SBJ triplet contains character data describing the
meeting subject. One SBJ triplet is allowed in each MTG structure and it
is optional.
PLACE (PLC)--The PLC triplet contains character data describing the meeting
location. One PLC triplet is allowed in each MTG structure and is
optional.
DETAIL (DTL)--The DTL triplet contains character data describing the
meeting. If the Code Page or character Set is changed in the meeting
description, the DTL triplet must be ended, a SCG triple inserted, and
another DTL triplet built. It is optional.
RSVP (RVP)--The RVP specifies the need for an attendance response from the
meeting invitee and it is optional.
If a MTG structure is received without all required triplets, an exception
exists. The default action is to skip the structure and continue
processing. If a MTG structure contains an unsupported or invalid triplet,
an exception exists. The default action is to skip the triplet and
continue processing. If a MTG structure contains a DTT triplet with dates
and times not in ascending order or if the optional SCG triplet occurs at
a position that does not immediately precede a triple with text data (DTL,
SBJ, PLC), an exception exists. The default action, in both cases, is to
ignore the triplet and continue processing.
NAMES LIST (NML) DATA STRUCTURE
The names list data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure
NUM * 32767 2 R
Length
2 Structure
COD X`D3` X`D3` 1 R
Type1
3 Structure
COD X`8A` X`8A` 1 R
Type2
4-3+n
NML * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The NML structure provides the fields to support a name, associated
addresses and status. The NML may contain a list of items, such as an
invitees list, by concatenating Name (NME), Address (ADR) and User Status
(UST) sequences. The list may include one or more than one name and
associated information.
The following Valid NML Triplets for the NML DS were described in
connection with the MTG structure.
ERROR ACTION, STRUCTURE ID, TIME STAMP, ENTRY SECURITY, SET CGCSGID, NAME,
USER STATUS, NETWORK ADDRESS and POSTAL ADDRESS.
The Date and Time (DTT) triplet is not valid. The following triplet,
however, is optional for the Names List data structure.
NAMES LIST TYPE (NLT)--Only one NLT triplet is allowed in the Names List
structure. The NLT triplet specifies the type of data contained in the
Names List. If the NLT is not specified, the list contains a list of names
and or status and/or addresses that are not necessarily in one of the
categories defined by the NLT triplet.
If an NML structure is received without a Structure ID triplet, an
exception exists. The default action is to skip the structure and continue
processing. If an NML structure contains an unsupported or invalid
triplet, and exception exists. The default action is to skip the triplet
and continue processing. Each sequence of the
Names List structure triplets must occur in the listed order. Optional
triplets may be omitted from any sequence. If a NML structure is received
with a triplet out of sequence, an exception exists. The default action is
to skip the structure and continue processing. The above-described
processing for handling exceptions is standard for most structures and
therefore can be assumed for the following items.
VIEW SELECT (VSL) DATA STRUCTURE
The View Select data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure
NUM * 32767 2 R
Length
2 Structure
COD X`D3` X`D3` 1 R
Type1
3 Structure
COD X`95` X`95` 1 R
Type2
4-3+n
VSL * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The VSL structure provides a way to request calendar views for specific
category(s) and timespan(s).
The Valid VSL Triplets previously described include the ERROR ACTION (EAC),
USER DEFINED FIELD (UDF) and DATE and TIME (DTT) triplets.
The following triplet is also optional and valid.
ENTRY CATEGORY (ECT)--The ECT selects the category(s) for the calendar
entry(s) to be selected in the view request. Only one ECT is allowed in a
View Select structure. When more than one category is selected in the ECT,
the view returned will contain the selected categories. If both the ECT
and UDF triplet are omitted, all entries in the selected timespan will be
returned.
The DTT triplet dates and times must occur in ascending order. The first
DTT processed must provide the earliest date and time block. The last DTT
processed must provide the latest date and time block. The first DTT also
provides the begin date and time for the timespan selected.
When the optional ECT triplet is present, the VSL triplets must occur in
the order ECT, DTT.
CALENDAR TRIPLETS DETAIL DESCRIPTION
This section describes in detail the set of calendar triplets that are the
building blocks designed to be used by the Calendar Structures of the
system including those described in the previous section.
The previous section indicated where these triplets are valid.
The triplets are described in alphabetic order.
In the triplet descriptions, bits are consecutively numbered from left to
right starting with zero.
The format for all of the triplets is the same and is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0 LENGTH NUM R
1 KEYWORD COD R
2-n PARM1 to R
PARMn
______________________________________
where
LENGTH=A one-byte value of the number of bytes in this triplet including
byte zero.
KEYWORD=a one-byte binary number that designates a specific triplet
function.
PARM1 to PARMn=Parameters containing the triplet settings.
The length of some triplets can vary depending on the number of parameters
specified. If the length excludes an optional parameter or part of an
optional parameter, then the value for that parameter and any parameters
that follow are not changed; that is, the LENGTH field is used as
specified. If a triplet is received in which the length exceeds the
maximum value required to include all parameters, an exception is raised
since the additional values are considered to be unsupported parameters.
Also, if the length field excludes a required parameter, an exception is
raised.
Since bytes 1 and 2 of all the triplets are identical, they are not shown
for each triplet. Only bytes 2 through n will be described.
NETWORK ADDRESS (NAD) TRIPLET DATA STRUCTURE
The NAD triplet data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
2-n Network Ad- COD * * 16 0
dress
______________________________________
The NAD triplet provides the Network Address for the item named in the
(NME) triplet.
The NAD Parameters include,
NETWORK ADDRESS--This is the person's Network Address.
Bytes 2 through 9=USER ID
BYTES 10 through 17=NODE ID
POSTAL ADDRESS (PAD) TRIPLET DATA STRUCTURE
The PAD triplet data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
2-n Postal Address
COD * * 1-253 0
______________________________________
The PAD triplet provides the Postal Address for the item named in the (NME)
triplet.
The PAD Parameters include,
POSTAL ADDRESS--This is the person's Postal Address. Valid values are valid
characters in the active or selected code page.
PROCESS ID (PRD) TRIPLET DATA STRUCTURE
The PRD triplet data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
2-n Process COD * * 1-16 0
______________________________________
The PRD triplet specifies the ID of a process such as a computer program.
The PRD Parameters include,
PROCESS -A 1 to 16 byte identifier. Valid values are valid characters in
the active or selected code page.
DATE AND TIME (DTT) TRIPLET DATA STRUCTURES
The DTT is shown below.
__________________________________________________________________________
BYTES
NAME TYPE
| | |
