WD-xml-link-970305[Mirrored from: http://www.textuality.com/sgml-erb/WD-xml-link.html]
WD-xml-link-970305 This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/pub/WWW/TR.
Note: Since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
This work is part of the W3C SGML Activity (for current status, see http://www.w3.org/pub/WWW/MarkUp/SGML/Activity).
This document specifies a simple set of constructs that may be inserted into XML documents to describe links between objects. It is a goal to use the power of XML to create a structure that can describe both the simple unidirectional hyperlinks of today's HTML, as well as more sophisticated multi-ended, typed, self-describing links.
This document specifies a set of constructs which may be inserted in XML documents to describe links between objects (the objects may or may not be XML). A link, as the term is used here, is a relationship which is asserted to exist between two or more data objects or portions of data objects. This specification is concerned with the syntax used to assert link existence and describe link characteristics. The existence of an implicit unasserted relationship, for example that of of one word to the next, or from a word to its entry in an on-line dictionary, is not considered a link here. Obviously this does not cover all the useful kinds of links, and there is no intent, in this specification, either to provide machinery for all such types, nor to preclude applications using the XML linkage machinery from also using other more elaborate mechanisms.
The existence of links is asserted by the presence of elements contained in XML documents. They may or may not reside at the locations of, or in the same documents with, the objects which they serve to connect.
This specification is part of the overall XML effort, on which see .... It aims to provide an effective yet compact structure for representing links that can be in documents or external to them, that can have multiple typed locators, indirection, and precise specification of resource locations in all kinds of data. It also aims to represent the abstract structure and significance of links, leaving formatting issues to stylesheets or other mechanisms as far as practical.
Three standards have been especially influential:
Many other linking systems have also informed this design, including Dexter, MicroCosm, and InterMedia.
The following basic terms apply in this document. (figure to be inserted)
Many papers have been written on how to categorize links by type. This specification provides ways to state a link's type along several axes, but only provides a standard vocabulary for the first kind of typing, namely link relationships. The vocabulary of link types can be extended by creating sub-types at all levels.
The existence of a link is asserted by a linking element. These must be recognized reliably by software in order to provide appropriate display and behavior. XML linking elements are recognized based on the use of a specially reserved attribute named XML-LINK. Possible values are LINK, XLINK, LOCATOR, XLG, and XLD, signalling in each case that the element in whose start-tag the attribute appears is to be treated as an element of the indicated type, as described in this specification.
An example of such a link:
<A XML-LINK="LINK" HREF="http://www.w3.org/">The W3C</A> |
There are two distinct mechanisms that may be used to associate the XML-LINK attribute with a linking element. The simplest is to provide it explicitly, as in the example above. However, this practice is verbose, and would be not only cumbersome but wasteful of network bandwidth in the case where there are large numbers of linking elements. Fortunately, XML's facilities for declaring default attribute values can be used to address this problem. For example, suppose one wished to declare the "A" element to be an XML LINK. The following would accomplish this:
<!ATTLIST A XML-LINK CDATA #FIXED "LINK"> |
The declaration above is simple. The decision of where to place it, however, must be made with care. Such a declaration may be placed in either the external or internal subsets of the Document Type Declaration. However, in a valid XML document, the declaration cannot be placed in both subsets, because for compatibility with SGML, XML forbids the use of more than one attribute list declaration for an element type.
Since it is often expensive and unnecessary for a network client to download the external DTD subset, it would seem that the natural place for the XML-LINK declaration is in the internal subset, which is included in the data transmitted over the network. This would require that to maintain validity, the declaration would need to be removed from the external subset. In practical terms, the maintenance of a DTD which is contained mostly in the external subset, but a small portion of which must appear separately in the internal subset of each document to be transmitted over the network, would be an onerous administrative task.
This conflict between administrative simplicity and document validity is, in the long run, not acceptable. It may soon be resolved by a change to the SGML standard that would allow multiple attribute list declarations per element type; in this case, the XML-LINK attribute could safely be declared in the internal subset without regard to whether it also appears in the external subset.
However, this change to SGML may end up not being made; in which case, this specification will be expanded to provide another technique for declaring which element types are to be treated as XML linking elements, without the overhead of attaching attributes to them every time they appear.
This specification defines two types of linking elements. First, a simple link (LINK), which is always in-line and one-directional, very like the HTML <A> element. Second, a much more general extended link (XLINK) which is out-of-line and may be used for multi-directional links, links into read-only data, and so on.
This specification describes a variety of information that may be (and in some cases is required to be) associated with linking elements:
RoleROLE attribute is used for both link and resource roles. A set of pre-defined link roles is included in this specification. A sub-role may be created by appending "." and the sub-role name. This process may be repeated in order to create role hierarchies.ResourceHREF, HRTYPE, LOCSRC, IMPLIED-LOCSRC) as described in the Addressing section of thius specification.LabelTITLE attribute. This specification does not require that applications make any particular use of the label.BehaviorSHOW and ACTUATE attributes may be used for an author to communicate general policies concerning the traversal behavior of the link; this specification defines a small set of policies for this purpose. The BEHAVIOR attribute may be used to communicate detailed instructions for traversal behavior; this specification does not constrain the contents, format, or meaning of this attribute. A extended link can involve any number of resources, and need not be co-located with any of them. An application may be expected to provide traversal between all of them (subject to semantic constraints outside the scope of this paper). The key issue with extended links is how to manage and find them, since they do not necessarily co-occur with any of their resources, and often are located in completely separate documents. This process is discussed under Link Groups below.
A extended link's locators are contained in child elements of the linking element, each with its own set of attributes. In the following declaration of the XML the extended link, note that the element types do not need to be those given, since the linking element will be recognized based on the XML-LINK attribute:
<!ELEMENT XML-XLINK (#PCDATA | XML-LOCATOR)*> |
Simple links are very much like HTML <A> or TEI <XREF> elements, but with more general reference capabilities. A simple link may contain only one locator; thus there is no necessity for a separate child element, and the locator attributes are attached directly to the linking element. The location where the linking element is placed is not required to act as a resource; that is to say, there is no requirement that this location can be reached from the explicit resource, though applications are free to provide that capability if they have a means of knowing that the linking element exists.
Once again, in the following declaration, the linking element type need not be XML-LINK:
<!ELEMENT XML-LINK ANY> |
Linking elements assert the existence of links. The traversal of a link requires the use of one or more locators to access and process the corresponding resources.
This specification provides a mechanism for the authors of linking elements to signal their intentions as to the timing and effects of traversal. These intentions can be expressed along two axes, labeled SHOW and ACTUATE. These are used to express policies rather than mechanisms; programs which are processing links in XML documents are free to devise their own mechanisms, best suited to the user environment and processing mode, to implement the requested policies.
In many cases, there will be a requirement for much finer control over the details of traversal behavior; existing hypertext software typically provides such control. Such fine control of link traversal is outside the scope of this specification; however, the BEHAVIOR attribute is provided as a standard place for authors to provide, and in which programs should look for, such detailed behavioral instructions.
The SHOW attribute is used to express a policy as to the context in which a resource that is traversed to should be displayed or processed. It may take one of three values:
INCLUDEREPLACENEW
The ACTUATE attribute is used to express a policy as to when traversal of a link should occur. It may take one of two values:
AUTOUSERLinks can involve many kinds of data as resources:
Note also that there is no requirement that a resource be a singular data object; there is sufficient opacity in addressing methods that a single locator might in fact address multiple data objects, which together would be considered a resource.
A special case arises when the resource indicated by a locator proves to be another linking element. When an application traverses or displays such a link, it may be desired to read and traverse that link to whatever its resource(s) is (are) and operate on the result of that traversal. This has the benefit of allowing greatly increased indirection and flexibility; on the other hand, it might lead to potentially unbounded delays in traversing simple-looking links. This specification does not constrain the behavior of applications in this situation.
Each locator is required to address a resource using an HREF (HREF may have at one point stood for "Hypertext reference"; the name is adopted for compatibility with existing practice). An HREF is a character string containing the information used to address the resource. An HREF may operate as a locator, as with a URL, a name, as with a URN or SGML FPI, or a query.
An HREF may be accompanied by a Reference Type, a name which identifies the interpretation of the HREF.
The HREF and reference type are provided, respectively, in the HREF and HRTYPE attributes.
Many addressing mechanisms assume the existence of some sort of a base address whose value effects the interpretation of the address. To formalize this, every HREF has a location source, an object or objects which serves as the base address. In most cases the location source can be omitted and is implied to be the document element of the document that contains the link. However, this implied location source can also be specified as being the non-link element that refers to the link element (the referrer).
The location source is specified using the the location-source attribute. The format of the location-source string is not specified; to be useful, clearly it must be in a form that can be processed by the processor that can deal with the HREF and reference type to which it is attached. If the location-source attribute is omitted, the location source is implied according to the rule indicated by the IMPLIED-LOCSRC attribute.
The implied-locsrc attribute takes one of the values REFERRER or DOCELEM. The value REFERRER indicates that the implied location source is the referrer element. The value DOCELEM indicates that the location source is the document element, the document's root element.
The default value for implied-locsrc is DOCELEM.
SGML HREFs use standard SGML Element and Entity addressing mechanisms. If the reference type is ENTITY, then the HREF must be an entity name which references an external entity. If the reference type is ELEMENT, then the HREF must be the value of a unique identifier attribute within the current document. If the reference type is SGML, then the HREF must contain an entity name interpreted as with ENTITY, followed by the character "#", followed by the value of a unique identifier attribute within the document referenced by the leading entity name.
If the reference type is URL, then the HREF must be a URL.
URLs may be used to refer to data objects of any kind.
If the reference type is TEI, the HREF must be a TEI locator.
XML uses a subset of the syntax defined for TEI extended pointers. These operate on groves as defined in DSSSL, using the grove plan (set of structural information) specified in HyTime. Every construct in such locators has a corresponding expression in DSSSL's SDQL query language, and most also have direct equivalents in the HyTime location module. A full description of the syntax is available in the TEI Guidelines; a summary appears as Appendix A of this document.
The basic form of such a locator is a series of location terms, each of which specifies a location, either absolute or (more frequently) relative to the prior one. Each term has a name, such as ID, CHILD, ANCESTOR, and so on, and can be qualified by parameters such as an instance number, element types, or attributes. For example, the locator string "CHILD (2 CHAP) (4 SEC) (3)" refers to the 3rd child of the 4th SEC within the 2nd CHAP within the referenced document.
Such a locator can be considered a query, and the extended pointer syntax a query language. Thus it can be appended to a URL that identifies an appropriate document, in order to locate some portion of that document; or can be declared as a HyTime query, and thus used in a fully HyTime-conforming manner. [need to add an example of the necessary declarations, similar to Eliot's straw proposal].
XML omits some features of TEI extended pointers:
[We may want to include a proposed TEI addition that provides for pointing directly to the values of attributes per se]
[Add a way to specify additional query languages]
XML describes the syntax of link elements embedded in documents. Many applications, when processing a document, may wish to process not only the links embedded in that document, but links in other documents which point into it. For example, it may be desirable to highlight the resources of such links to make the linkage network's existence apparent. In other words, it may be appropriate to process, rather than a single document, a group of interlinked documents.
In these cases, the Extended Link Group (XLG) element may be used to store a list of identifiers of other documents that together constitute an interlinked document group. Each such document, which must be known as an external text entitiy, is identified using the DOC attribute of an Extended Link Document (XLD) element, which is a child element of the XLG.
XLG and XLD elements, just as with XLINK, LINK, or LOCATOR elements, may be recogized by the use of the XML-LINK attribute with the values XLG or XLD.
Here is the declaration for the XML form of the XLG and XLD elements:
<!ELEMENT XML-XLG (XML-XLD*)> |
Extended links may only occur in restricted contexts, in order to facilitate software finding them (their related resources, of course, may be anywhere at all).
First, extended links may occur in the LINKS element of a document, which is part of its header. So long as any part of the document remains open, all resources of all extended links in the header shall be known to the software and available to the user. Applications may apply their own conventions for when a document is no longer considered "open", except that any document any part of which remains in view, is open by definition.
Second, extended links may occur in separate documents that contain only extended links, called LINKSETS. Any document may specify any number of other documents and/or LINKSETS that should be opened. All resources specified in a LINKSET shall remain active at least as long as any of documents that points to that linkset remains open. [There is an argument to be made for keeping them open longer, such as for a whole session, or while any documents that have resources in the linkset are open; or for letting the referencing document(s) state how long they want it open; etc]. Software shall also provide a way for users to specify global or other LINKSETS, which should be kept open more persistently, such as throughout an entire user session, or automatically for all user sessions.
Each location pointer specification consists of a sequence of location term s, each of which consists of a keyword specifying a location type followed by one or more parenthesized parameter lists, each of which specifies a location value via a list of parameters. Location types and values, and the parameters within a location value, must be separated by white space characters.
Using terms borrowed from HyTime , we say that each TEI location term in a specification provides the location source for the next, and the entire specification is equivalent to a location ladder . By specifying the entire ladder in a single attribute value, the TEI extended pointer mechanism greatly reduces the syntactic and processing complexity of hypertextual pointers.
In formal terms:
ladder ::= locterm | ladder locterm |
The keywords used in location terms are these; references to the tree mean the tree representing the SGML document hierarchy.
roothereidrefchilddescendantancestorpreviousnextprecedingfollowingpatterntokenstrspaceforeignIn formal terms:
locterm ::= 'ROOT' // default first location |
The keywords are not case sensitive.
Each location term specifies a location in the target document; this location may be a single point, more often a span of text (often the span of a single element) within the target document. The location ladder as a whole is interpreted from left to right, and each location term specifies a location relative to the location specified by the sequence prior to that point (i.e. to its location source). Unless here or id is specified as the first location term, the beginning location source is always root . An empty location sequence thus is the same as root and specifies the entire destination entity.
Some of the location terms make sense only in documents that have tree-like representations; these are id , child , ancestor , descendant , previous , next , preceding , and following . The latter six involve traversing the tree representing the SGML document hierarchy and are most easily understood when their location source is a single SGML element. If the location source is not a single SGML element, the tree-traversal keywords operate upon its beginning end-point, its front end (in English, this will be the leftmost point of the location source; in Arabic or Hebrew it will be the rightmost point). In this case child and descendant have no meaning, since character data has no descendants in the document tree; the first ancestor of such a location source is the element immediately containing the character data in question, and the siblings referred to by next and previous are the other children of that immediately containing element.
The details of each keyword are given below, along with definitions of their syntax and semantics of their results. Examples are also provided. It is strongly recommended that when IDs are available, they should be used in preference to the other methods for pointing defined here.
For all keywords, the description assumes that the target document does in fact contain a span or element which matches the description; otherwise, the location term has no referent and is said to fail . If any location term fails, the entire pointer fails. No backtracking or retrying is performed.
The location term root selects the document element. Since root is assumed as the implicit first term in any ladder, the following two location ladders have the same meaning:
ROOT DESCENDANT (2 DIV1) DESCENDANT (2 DIV1) |
The keyword here designates the location at which the pointer element itself is situated; it allows extended pointers to select items like the paragraph immediately preceding the one within which this pointer occurs . Since it ignores any existing location source, this keyword typically makes sense only as the first location term in a location specification.
To designate the paragraph preceding the current one , the following location ladder could be used:
HERE ANCESTOR (1 P) PREVIOUS (1 P) |
(See below for descriptions of the keywords ancestor and previous .)
The resulting location is the element within the destination entity whose ID attribute has the value specified as the location value.
For example, the location specification
ID (a27) |
chooses the necessarily unique element of the destination entity which has an attribute of declared value of type ID, whose value is a27 .
The child location type specifies an element or span of character data in the document hierarchy using a location value which functions as a domain-style address. The value is a series of parenthesized steps, separated by white space. Each such step represents one level of the hierarchy within the location source. Each step may contain one or more parameters separated by white space and interpreted in order as follows:
ALL
In formal terms, the location value of child is a series of steps :
steps ::= '(' step ')' | steps '(' step ')' step ::= |
Location values of the same form are also used by the keywords descendant , ancestor , previous , and next.
If an instance indicator alone is specified, as a number n , it selects the n th child of the location source. If the special value ALL is given, then all the children of the location source are selected. If the instance indicator is specified with following parameters, it selects all, or the n th, among those children of the location source which satisfy the other parameters. Negative numbers count from the last child of the location source to the first. The location source must contain at least n children; if it does not, the child term fails.
In formal terms, the first parameter of a step is an instance indicator, which in turn is either the special value ALL or a signed integer:
instance ::= 'ALL' | signed signed ::= NUMBER |
If a second parameter is given, it is interpreted as an SGML generic identifier, and only elements of the type indicated will be selected. For example, the location specification
CHILD (3 DIV1) (4 DIV2) (29 P) |
chooses the 29th paragraph of the fourth sub-division of the third major division of the initial location source.
Constraint by generic identifier is strongly recommended, because it makes links more perspicuous and more robust. It is perspicuous because humans typically refer to things by type: as the second section , the third paragraph , etc. It is robust because it increases the chance of detecting breakage if (due to document editing) the target originally pointed at no longer exists.
The generic identifier may be specified as a normal SGML name or using the reserved values #CDATA or * . If the generic identifier is specified as * , any generic identifier is matched; this means that CHILD (2 *) is synonymous with CHILD (2) . If the second parameter is #CDATA , the location term selects only untagged sub-portions of an element having SGML mixed content.
The location ladder
CHILD (3 #CDATA) |
thus chooses the third span of character data directly contained by the current location source. If the location source is a paragraph containing
CHILD (3 #CDATA) selects sentence C, while CHILD (3) selects sentence B.
If specified as a name, the generic identifier is case sensitive if and only if the SGML declaration specifies that generic identifiers are case sensitive (by default they are not).
In formal terms the second parameter of a step is defined thus:
element ::= NAME | '#CDATA' | '*' | |
The third and fourth parameters, if given, are interpreted as an attribute-value pair, and only elements which match that pair in the way described below will be selected; the fourth and fifth parameters, and all following pairs of parameters, are interpreted in the same way. When more than one pair is given, all must be matched.
The third, fifth, seventh, etc., parameters are interpreted, if specified, as attribute names. Like generic identifiers, attribute names may be specified as * in location ladders in the (unlikely) event that an attribute value constitutes a constraint regardless of what attribute name it is a value for.
For example, the location term
CHILD (1 * TARGET *) |
selects the first child of the location source for which the attribute target has a value.
As with generic identifiers, attribute names are case sensitive if and only if the SGML declaration says they are.
In formal terms, the attribute-name parameter of a tree-traversal step is defined thus:
attribute ::= NAME | '*' |
If a fourth, sixth, eighth, etc., parameter is specified, it is interpreted as an attribute value, and only elements satisfying the other constraints and also bearing an attribute of the specified name and value will be selected. The attribute value may be specified exactly as in an SGML document; as a consequence, if the attribute value to be specified contains white space characters, it must be enclosed in quotation marks. The attribute value may also be specified using the two special values #IMPLIED and * .
For example, the location specification
CHILD (1 * N 2) (1 * N 1) |
chooses an element using the global n attribute. Beginning at the location source, the first child (whatever kind of element it is) with an n attribute having the value 2 is chosen; then that element's first direct sub-element having the value 1 for the same attribute is chosen.
If specified with quotation marks or as a regular expression, the attribute-value parameter is case-sensitive; otherwise not.
The location specification
CHILD (1 FS RESP #IMPLIED) |
selects the first child of the location source which is an fs element for which the resp attribute has been left unspecified.
In formal terms, the attribute-value parameter of a tree-traversal step is defined thus:
value ::= LITERAL // i.e. quoted string. | |
If the descendant keyword is used, the location term selects an element or character-data string which is a descendant of the current location source. The parameters are the same as for child. The set of elements and strings which may be selected, however, is the set of all descendants of the location source (i.e. the set of all elements contained by it), rather than only the set of immediate children.
The location specification
ID (a23) DESCENDANT (2 TERM LANG DE) |
thus selects the second term element with a lang of de occurring within the element with an id of a23 . The search for matching elements occurs in the same order as the SGML data stream; in terms of the document tree, this amounts to a depth-first left-to-right search.
If the instance number is negative, the search is a depth-first right-to-left search, in which the right-most, deepest matching element is numbered -1, etc. The location specification
DESCENDANT (-1 NOTE) |
thus chooses the last note element in the document, that is, the one with the rightmost start-tag.
The ancestor location term selects an element from among the direct ancestors of the location source in the document hierarchy. The location value is of the same form as defined for the child. However, the ancestor keyword selects elements from the list of containing elements or ancestors of the location source, counting upwards from the parent of the location source (which is ancestor number 1) to the root of the document instance (which is ancestor number -1).
For example, the location term
ANCESTOR (1 * N 1) (1 DIV) |
first chooses the smallest element properly containing the location source and having attribute n with value 1 ; and then the smallest div element properly containing it.
The previous keyword selects an element or character-data string from among those which precede the location source within the same containing element. We speak of the elements and character-data strings contained by the same parent element as siblings ; those which precede a given element or string in the document are its elder siblings ; those which follow it are its younger siblings .
The instance number in the location value of a previous term designates the nth elder sibling of the location source, counting from most recent to less recent. The location ladder
ID (a23) PREVIOUS (1) |
thus designates the element immediately preceding the element with an id of a23 . Negative instance numbers also designate elder siblings, counting from the eldest sibling to the youngest. The location source must have at least as many elder siblings as the absolute value of the instance number. If the location source has at least one elder sibling, then the location term
PREVIOUS (-1) |
designates its eldest sibling and is thus synonymous with the ladder
ANCESTOR (1) CHILD (1) |
The value ALL may be used to select the entire range of elder siblings of an element: the location ladder
ID (a23) PREVIOUS (ALL) |
thus designates the set of elements which precede the element with an id of a23 and are contained by the same parent.
The keyword next behaves like previous , but selects from the younger siblings of the location source, not the elder siblings. The location ladder
ID (a23) NEXT (1) |
thus designates the element or string immediately following the element which has an id of a23 . Negative instance numbers also designate younger siblings, counting from the youngest sibling to the location source. The location source must have at least as many younger siblings as the absolute value of the instance number. If the location source has at least one younger sibling, then the location term
NEXT (-1) |
designates its youngest sibling and is thus synonymous with the ladder
ANCESTOR (1) CHILD (-1) |
The preceding keyword selects an element or character-data string from among those which precede the location source, without being limited to the same containing element. The set of elements and strings which may be selected is the set of all elements and strings in the entire document which occur or begin before the location source. (For purposes of the keywords PRECEDING and FOLLOWING , elements are interpreted as occurring where their start-tag occurs.) The PRECEDING keyword thus resembles PREVIOUS but differs in searching a larger set of strings and elements; its result is not guaranteed to be a subset of its location source.
The instance number in the location value of a preceding term designates the nth element or character-data string preceding the location source, counting from most recent to less recent. The location ladder
ID (a23) PRECEDING (5) |
thus designates the fifth element or string before the element with an id of a23 . Negative instance numbers also designate preceding elements or strings, counting from the eldest to the youngest; the ladder The location source must have at least as many elder siblings as the absolute value of the instance number; otherwise, the preceding term fails. The value ALL may be used to select the entire portion of the document preceding the beginning of the location source.
The keyword following behaves like preceding , but selects from the portion of the document following the location source, not that preceding it.
The token keyword selects a sequence of one or more tokens chosen from within the character content of the location source, where tokens are counted exactly as for the corresponding HyTime dataloc form with quantum=word. The location value must be either a single positive integer, or a pair of positive integers separated by white space, representing the first and the last token numbers to be included in the resulting location. If two integers are specified, the second must not be less than the first. The location source must contain at least as many tokens as are specified in the location value.
This location type must not be used to count across element boundaries.
For example, the location specification
ID (a27) TOKEN (3 5) |
chooses the 3rd, 4th, and 5th tokens from the content of the element whose identifier is a27 . If this element contained the string This is _not_ a very good idea , the target selected would be not_ a very .
In formal terms the location value of the token and str keywords is defined as a range:
range ::= NUMBER | NUMBER NUMBER |
The space location term applies to entities which represent graphical or spatio-temporal data; typically such entities are not encoded in SGML, but in one of many specialized graphical formats. SGML provides standard mechanisms (the NOTATION declaration and related constructs) for specifying what format such an entity uses.
The location value for space consists of two or three parenthesized parameter lists. The first contains the name of the co-ordinate space in use. The second and third each consist of any number of signed integers. The numbers in a parameter list represent locations along each dimension of a Cartesian co-ordinate space with all axes orthogonal; the length of the list equals the number of dimensions/axes of the space (usually, but not inevitably, 2, 3, or 4).
If the third parameter list is not specified, the location is the single point in the co-ordinate space specified by the second parameter list. If all three parameter lists are specified, the location is the rectangular prism defined by treating corresponding items of the second and third lists as inclusive bounds along each dimension in turn.
The mapping from co-ordinates to physical or display space, and the meaning and ordering of the axes, are not defined by these guidelines. They should be specified in the TEI header unless they can be determined by definition from the format in which the referenced entity is known to be encoded (for example, many graphics formats can only encode locations in units of pixels, counted in a 3 dimensional left-handed co-ordinate space).
Time may be construed as an axis in addition to any others; when it is, it is TEI recommended practice that it be positioned last. The units used must be defined in the TEI header; it is acceptable in certain media (such as videodiscs) to use frame numbers as a surrogate axis for time.
For example,
SPACE (2D) (0 0) (1 1) |
specifies the location of the unit square tangent to the origin in quadrant 1 of a common graph.
The location value for a space location term is a NAME enclosed in parentheses, followed by a point pair:
pointpair ::= '(' numbers ')' | '(' numbers ')' '(' numbers |
The foreign keyword takes any number of parenthesized parameter lists, and is terminated by the end of the attribute value, or by the next non-parenthesized token, whichever comes first.
The meaning of the foreign location term is not defined by these Guidelines. It is intended for use in pointing to special kinds of non-SGML, non-coordinate space data. That is, it should be used for making links to data which cannot be specified using the other mechanisms. The meaning of any foreign location types must be specified in the TEI header, as a series of paragraphs at the end of the encodingDesc element defined in section * . If more than one such type is used, it is TEI recommended practice that the first parameter list to foreign be a name associated with the particular type by documentation in the TEI header.
For example, assume that some program uses a proprietary data format called XFORM, and that the program has supplied an identifier 06286208998 for some piece of data it owns. Then the location specification
FOREIGN (XFORM) (06286208998) |
would be one way of expressing a link to that piece of data.
The HTML copy of this draft specification was generated automatically from an XML source file using a custom formatter written in perl.