|
Formatting
Specifications
Introduction
Three basic types
of constructs called formatting specifications are used in WebZ
rules-based formatting. They are defined inside various formatting
configuration files for the WebZ
interface and are the building blocks of rules-based formatting
functionality. This topic discusses these three specifications by providing
definitions, examples, and the syntax for each of them.
Display
Specifications
Rule
Specifications
Field Specifications
Display
Specifications
A display specification
is one of two important formatting constructs in a formatting
configuration file. It is a set of instructions that creates the
elements in a display by ultimately executing a series of Java classes
known as "formatting rules."
Example Display Specification:
[brief]
characterset = ASCII/EBCDIC/UTF8/ASIS
doHtmlDiacritics = true
rule* = bookmarkFromBrief
rule* = recordnumber
rule* = dataLabel
rule* = brieftitle
rule* = briefauthor
rule* = databaseName
rule* = briefdate
rule* = updateCurrecno
rule* = dataTrailer |
| Note: |
The display
specification above was extracted from the MarcArticleFormats.ini
file for the WebZ Out-of-the-Box Interface (OBI), version 1.
|
Syntax
of a Display Specification
The following
table breaks down the syntax of a display specification into its possible
parameters.
|
Element
|
Description
|
|
[section
name]
|
This identifies
the particular set of rules that correspond to a format type listed
under the [Formats] section in a database
configuration file. (See the diagram under Display
Formatting Configuration Files for an illustration of the
relationship between the section name for a display specification
and the format type in a database configuration file.)
|
| characterset
(optional) |
This
parameter defines the character set of the input data. ASCII is the
default |
| doHtmlDiacritics
(optional) |
This
parameter defines whether the data is to be displayed as HTML (true)
or as text (false). The default is true, however, it should be set
to false in a TEXT display for email or print. When this parameter
is true, any hot links will be created. |
| rule |
This
parameter references a rule specification
that creates an element in the display by executing a Java class. |
Rule
Specifications
At the root of
rules-based formatting functionality is the central concept that each
display element has its own rule specification, which ultimately executes
a formatting class. A rule specification is the second of the two most
important formatting constructs contained in a formatting
configuration file (its partner, the display specification is
the other one). The rule specification syntax makes it possible for you
to define or modify an element by simply defining or modifying its rule
specification. A rule specification is both the most essential and most
basic structure you use to define and modify how data is formatted for
the WebZ Interface.
Example Rule Specifications:
|
[bookmarkFromBrief]
class = ORG.oclc.fmts.rules.AddSaveButton
nextPage = $StyleTable.pages.bookMarkFromBrief;
[recordnumber]
class = ORG.oclc.fmts.rules.AddRecordNumber
[dataLabel]
class = ORG.oclc.fmts.rules.AddWrapperData
wrapperName = beforeRecordData
[brieftitle]
class = ORG.oclc.fmts.rules.AddFetchAnchor
displayname = Title
field* = 245|a,b,n,p
field* = 246|a,b,n,p
missingData = No Title Provided
nextPage = &StyleTable.pages.fullDisplay;
badPage = &StyleTable.pages.badfetch;
format = F
command = /WebZ/FETCH
target = $StyleTable.targets.recordDisplay;
|
|
Note:
|
The
rule specifications above were copied from the MarcArticleRules.ini
file, which is included in the MarcArticleFormats.ini file for the
OBI, version 1. (See Sharing Formatting
Configuration Files for more information regarding the inclusion
of one ini file in another. |
Syntax of a Rule Specification
The following table
lists the parameters recognized by the rule specification.
|
Element
|
Description
|
|
[section
name]
|
This identifies
a particular rule specification in a formatting
configuration file.
|
|
class
|
This parameter
defines the Java class that implements the ORG.oclc.webz.DisplayRule
interface that, in turn, generates a data string based on parameters
given to it from the rule specification. The default class, ORG.oclc.fmts.rules.AddRecordData,
is used when the class parameter is omitted.
|
| displayname
(optional) |
This
is the text label that is associated with the data in the display.
If omitted, no label is appended to the data. |
| field*
(dependent
on class) |
Dependent
on the class being executed, this parameter defines a field specification
when the class requires it. Multiple fields can be specified for a
rule specification by including additional field specifications. Field
specifications are executed in sequential order for the display. (For
the complete syntax of a field specification, see Field
Specification.) |
Field
Specification
Always included
as part of a rule specification when recognized
by its formatting class, a field specification
defines the data that is to appear in a field and it defines exactly how
that data is to be formatted for the display.
Example Field Specification:
|
field* = 600(sep='BREAK',trl='BREAK')|\
a,b,c,r,n,o,x,y,z(idx='sh=',sep=' -- ',trl='BREAK',repeatFldid=a)
field* = 610,650,651(sep='BREAK',trl='BREAK')|\
a,b,x,y,z(idx='sh=',sep=' -- ',trl='BREAK',dataordered,repeatFldid=a)
field* = 690(sep='BREAK',trl='BREAK')|\
a(idx='sh=',sep=' -- ',trl='BREAK',repeatFldid=a)
|
Syntax of a Field Specification
The following table
breaks down the syntax of a field specification into all its possible
parameters:
|
Element
|
Description
|
field*
= <fields>(optional field modifiers)|\
<subfields>(optional
subfield modifiers);\
<subfields>(optional subfield modifiers) |
This syntax
is used to define a list of record fields where full tag paths and
wildcards are valid.
|
|
Optional
Field Modifiers
|
| lab='<data>' |
This
string precedes the field data, but is not the text label as defined
in the rule. |
| sep='<data>' |
This
string separates repeating fields. If it is omitted, an empty string
is used. |
| trl='<data>' |
This
string trails the last field. If omitted, an empty string is used. |
| ind1='<data>'' |
This
is a list of valid indicator 1 values separated by commas. For example,
' ,1,2'. If omitted, indicators are not validated. |
| ind2='<data>' |
This
is a list of valid indicator 2 values separated by commas. For example,
' ,1,2'. If omitted, indicators are not validated. |
| idx='<index
label abbreviation>' |
This
is the index to be applied to one combined string generated by the
complete sub-field specification. This can be used when the sub-field
specification has multiple parts delineated by a semicolon. For example,
it can be used in complex Marc Subject headings where a hot-link query
should be the complete field and where different separators are used
for the different subfields. |
| repeatsfld='<subfield
identifier>' |
This
value can be either character or numeric and it indicates that each
time this subfield is encountered, the field separator is inserted. |
| dataordered
or formatordered |
This
is the order in which to process the fields. If omitted, the default
is data ordered. |
| BREAK |
This
keyword is to be used for line breaks. The software replaces it with
the correct break characters as defined in the linebreaks and dataWrappers
from display gadgets. |
| | |
This
is used to delimit fields from subfields. |
| <subfields> |
Full
tag paths and wildcards are valid. MARC fields a-z are allowed. Numeric
MARC fields 1-n must be specified using the numeric BER tags
starting with 27=MARC field 1. |
| Optional
Sub-Field Modifiers |
| lab='<data>' |
This
is the string that precedes the sub-field data, but is not the text
label as defined in the rule. If omitted, an empty string is used. |
| sep='<data>' |
This
string separates repeating subfields. If it is omitted, a space is
used. |
| trl='<data>' |
This
string trails the last subfield. If omitted, an empty string is used. |
| anchorsep='<data>' |
This
string separates repeating subfields in the anchor part of the string,
which can be different than what displays on the screen as part of
the hot-link. If omitted, a space is used. |
| dataordered
or formatordered |
This
is the order in which to process the fields. If omitted, the default
is data ordered.. |
| combine |
This
flag indicates that the subfields should be combined into one unit |
| idx='<index
label>' |
This
indicates that there is a QUERY anchor built for the subfield in the
index specified. |
| ;
(semicolon) |
It
delimits multiple sub-field specifications for the field list. It
is useful when creating anchors from selected subfields and non-anchors
from other subfields. |
| Note: |
For
lab, sep, and trl, if you want to escape a character, use the \ symbol.
For example, if you want sep = sub's, you would define it as, sep
= 'sub\'s' |
Example Field Specification
and Display
The following are
some field specifications from the OBI, version 1:
|
field* = 245|a
field* = 650,651,652(sep='BREAK',idx='sh=',ind1='0',ind2='2'|\
a-b(combine,sep=' ',dataordered,repeatFldid=a);\
c-w(sep='',dataordered);\ x,y,z(combine,sep='--',trl='BREAK',dataordered)
field* = 690(sep='BREAK',trl='BREAK')|\
a-v(idx='sh=',sep='',trl='BREAK',formatordered,repeatFldid=a)
|
Results
For the above field
specifications, all of subfield a for field 245 is appended together to
create a string.
For fields 650, 651,
and 652, indicator1=0 and indicator2=2 is validated for the field, then
a QUERY hot-link is created for the total formatted subfield string. Subfields
a and b are combined. When field a occurs, a break line is inserted. Subfields
c-w are appended with a separator of space. Subfields x,y, and z are appended
in data order to the subfield string.
For example:
| Input:
|
650
a) William Blake, d) 1785-1888 x) History y) music |
|
Output:
|
William
Blake, 1785-1888 (History and music are created as one hot link in
the sh= index.) |
And for field 690,
the repeated fields are separated by a line break and trailed by a line
break. Query anchors are created in the subject heading phrase index for
subfields a-v.
See Also
Formatting
Configuration Files
Formatting Classes
|