微信公众号 CCBible/Bible101/DBible 微博@基督徒百科@Bible101@歌珊地圣经引擎@如鹰展翼而上 QQ群 4619600/226112909/226112998 同步推送#今日真道圣言#

OSIS2.1用户手册:第六章

来自基督徒百科
跳转到导航 跳转到搜索

OSIS开放圣经信息标准2.1用户手册翻译

OSIS2.1用户手册:前言

OSIS2.1用户手册:目录

OSIS2.1用户手册:第一章

OSIS2.1用户手册:第二章

OSIS2.1用户手册:第三章

OSIS2.1用户手册:第四章

OSIS2.1用户手册:第五章

OSIS2.1用户手册:第六章

OSIS2.1用户手册:第七章

OSIS2.1用户手册:第八章

OSIS2.1用户手册:第九章

OSIS2.1用户手册:第十章

OSIS2.1用户手册:第十一章

OSIS2.1用户手册:第十二章

OSIS2.1用户手册:第十三章

OSIS2.1用户手册:第十四章

OSIS2.1用户手册:第十五章

OSIS2.1用户手册:第十六章

OSIS2.1用户手册:第十七章

OSIS2.1用户手册:第十八章

OSIS2.1用户手册:附录一

OSIS2.1用户手册:附录二

OSIS2.1用户手册:附录三

OSIS2.1用户手册:附录四

OSIS2.1用户手册:附录五

OSIS2.1用户手册:附录六

OSIS2.1用户手册:附录七

OSIS2.1用户手册:附录八

OSIS2.1用户手册:附录九

OSIS2.1用户手册:附录十

OSIS2.1用户手册:附录十一

OSIS2.1用户手册:附录十二

OSIS2.1用户手册:附录十三

OSIS2.1用户手册:附录十四

OSIS2.1用户手册:附录十五

OSIS2.1用户手册:附录十六

6. The OSIS header

The first element following osisText is required to be header. The header contains the revisionDesc,

work, and workPrefix elements for a particular work. These elements must be entered in that order,

although each may occur an unlimited number of times.

In other words, the order always is:

? <revisionDesc> elements (any number of them), followed by:

? <work> elements (any number of them), followed by:

? <workPrefix> elements (any number of them).

6.1. revisionDesc

The revisionDesc element is used to record changes or edits to the text and should be used every time

significant editing is done. Each revisionDesc element must contain a date element which says when those

edits were completed, in the form

yyyy.mm.ddThh.mm.ss

Note that all fields must have exactly the number of digits shown (4-digit year, 2-digit month, etc.). It is

permissible to omit the time and the preceding "T", thus giving just a date. For example, December 25th of

1999 CE would be:

1999.12.25

A date element in the revision description is followed by any number of p (paragraph) elements, in which the

changes made are summarized. The person responsible for making the changes should also be identified,

using the resp attribute on the revisionDesc element. The resp attribute records who made a change or edit

to the text.

Recommended practice is that more recent revisionDesc elements appear earlier in the document. That is,

entries should occur in reverse chronological order. For example:

<revisionDesc resp=”sjd”><date>2003.09.11</date>

Filling in the gaps. Adding some info for 2.0 as defined at the Calvin College meetings.

</revisionDesc>

<revisionDesc resp=”sjd”><date>2003.07.01</date>

sjd: Annotated alpha list of elements. Reworked reference and work sections and added type, scope, and explanations of type and subtype for work. Explained more elements and attributes.

</revisionDesc>

<revisionDesc resp=”sjd”><date>2003.06.17</date>

Wrote conformance section. Added lists of elements and attributes, USMARC list. Inserted placeholders for doc on all element types. Got document back to XML WF. Wrote CSS stylesheet.

</revisionDesc>

<revisionDesc resp="pld"><date>2005.11.01</date>

Conformed references to new OSIS 2.1 schema.

Added new examples to the text.

20

Added mapping to USFM codes

</revisionDesc>

Note that a separate revisionDesc element is used for each person responsible for changes in the text. Here,

‘sjd’ and ‘pld’ refer to Steve DeRose and Patrick Durusau, respectively. The use of such abbreviations is

common but by no means required.

Within a revisionDesc element, following the date element, it is possible to have as many p elements as are

necessary to describe the revision. It is better to have too full of a description of a revision than to have too

little information about a revision. Users should always err on the side of too many comments. Revision

comments will not appear in a normal rendition of the text.

6.2. work

A work element provides information comparable to that found on the title page of a printed work, using the

fields defined by the Dublin Core Initiative (see http://dublincore.org/).

The work element in the header with an osisWork attribute that matches the osisIDWork in the osisText

element identifies the work in which it occurs, like the title page in a printed work. For example:

<osisText osisIDWork="CEV" osisRefWork="Bible" xml:lang="en" canonical="true">

<header>

<work osisWork="CEV">

Note that the match between osisIDWork="CEV" in osisText and osisWork="CEV" in the work element

links this osisText to this particular work element.

Other work elements (ones that follow the first one) identify other works, much like a citation in a footnote

or bibliography in a printed work. Each assigns a local name to that work, using the osisWork attribute.

Works so declared can then be referred to in osisIDs or osisRefs throughout the text. For Bibles, this should

generally be the accepted acronym or abbreviated form of the translation's name (some standard version

abbreviations are listed above). No periods, hyphens, spaces, or colons are allowed in short names.

6.3. osisWork

The osisWork attribute of each work element provides a short name used to refer that work and its

declaration as a whole. As of version 2.1, OSIS specifies the recommended format described below for those

short names. When using the short name from an OSIS work element within the Dublin Core identifier

element, the type attribute must be set to "OSIS".

The first work element in the header must identify the work that is being encoded. It is used as the default

value for all osisIDs and osisRefs that do not have values or default values declared otherwise.

6.4. Work Prefix Defaults

Each work defined in the header is required to provide a short name for itself in the osisWork attribute.

These can then be used as prefixes (similar to XML namespace prefixes) on osisID, osisRef, and other

attributes throughout the rest of the document.

21In OSIS versions through 2.0, specific attributes were provided to set a default work prefix for osisIDs

(osisIDWork on the osisText element) and for osisRefs (osisRefWork on the osisText element). These

attributes remain available in OSIS 2.1, but a more general defaulting mechanism has been added.

In OSIS version 2.1 and later, the workPrefix element was added to make it possible to specify a default

work prefix for the attributes on any element in an OSIS document. The workPrefix element appears at the

end of the header, after all the work elements. Any number of workPrefix elements are allowed, each of

which sets the default work prefix for a particular attribute on a particular element type. For example:

 <workPrefix path="//note/@annotateRef" osisWork="Bible.KJV"/>

This declaration indicates that the default work prefix on all annotateRef attributes of note elements is to be

"Bible.KJV". No colon is to be included (the colon is used to separate a work prefix from the rest of a

reference when the work prefix is explicit rather than defaulted).

The syntax of the path attribute is taken directly from the W3C XPath Recommendation, and can be

correctly interpreted by any conforming XPath processor. (A path attribute is a means to specify a an

element in an XML document. The leading "//" means that this will find any note element in the document,

wherever it may be found.) However, the form shown above is the only form permitted at this time; more

complex XPaths are not permitted. In other words, the path attribute must consist of "//", an element type

name, "/@", and an attribute name. If a more detailed defaulting mechanism is required in the future, it will

likely be provided by permitting a wider range of XPath's features.

The w element has attributes which record the morphology and base form of a word (the morph and lemma

attributes respectively). Because the w element is so frequent when used, defaulting the prefix (which points

to a work defining the morphological of lexical system used) can save a lot of data entry effort, which will

minimize typing errors.