Work Items on XML-Link for the SGML WG

From section 0. Naming

0.1: What should the title of the spec be?
0.2: What should the generic term or acronym we use to reference whatever it is the spec describes?

From section 1. Introduction

1.a: Should links be expressed as SGML elements?
1.b: Should we exclude relationships such as containment and succession from this spec?
1.c: Should we define a link processor and specify any actions required of it?
1.d: Should we specify a way for a document to provide a summary of the linkage machinery it uses?
1.1.a: are formatting issues (aside from perhaps a metadata slot) outside of scope?

From section 1.3 notation

1.3.a: Should we assume that saying links are expressed using SGML elements and attributes, and describing them in SGML terms, is a satisfactorily complete syntax spec, thus avoiding a requirement for any BNF?
1.3.b: If links are SGML elements, should require XML-style reference concrete syntax + quoted attribute values? I.e. assert that all links would fit into XML docs?

From section 1.4 Terminology

Note: On this item, the ERB is leaning towards using the terms link, with the obvious meeting, pointer for the pointy bits that point at things, and for the third term, what the current spec calls anchor, the ERB is contemplating link end, end, and terminus. For the time being, and in order that Jon can read this without getting headaches, the spec has been adjusted to use link, pointer, and terminus.

1.4.a: What do we call the container used to hold the bits that point at other things?
1.4.b: What do we call the bits that point at other things?
1.4.c: What do we call the things that are pointed at?
1.4.d: What do we call the locator/adddress?
1.4.e: Should we get into talking about bi/multi directional links?
1.4.f: Should we define terms for links that are colocated with their ends, and if so, should we use in-line and out-of-line?
1.4.g: Should we define/discuss traversal?

From section 1.5 Types of link types

1.5.a: Shall we have a discussion of the characteristics links can can have, including relationship, topology, locator language, formatting, and behavior?

From section 2. Link recognition

2.1.a: Should we allow link recognition via a reserved attribute?
2.1.b: If so, should we generalize this and say that it's an AF?
2.1.c: If so, should we provide an introduction to AF's?
2.1.d: If we allow such recognition, what should the attribute be, and what should be the values for each element type we define?
2.2.a: Should we allow link recognition via a reserved GI?
2.2.b: If so, what should the set of GI's be?
2.3.a: Should we allow that processors can decide that something is a link for their own external reasons?

From section 3. Link types

3.a: The initial draft does not have any construct analogous to the "List Link" construct in Eliot's proposal. Do we need one?

From section 3.1 Information associated with links

3.1.a: Should we have a principle that all linkage information is encoded in GIs and/or attribute values, never in character data?
3.1.b: TYPE
3.1.c: ROLE
3.1.d: Anchor/locator/address
3.1.e: Explainer
3.1.f: Behavior
3.1.g: Formatting
3.1.h: Should other pieces of metadata besides those listed here be specified? For each, questions (i) - (vi) apply.
3.1.i: Should we allow links to contain other attributes than those described in the spec?
3.2.a: What should the generalized multiway link be called? Multilink (MLINK), General Link (GLINK), anything else?
3.2.b: Should the link-ends of a general link be given as attributes a la HyTime or as child elements, a la the initial draft?
3.2.c: Should we provide a content model for general links, and if link-ends are elements, for them?
3.2.d: Should we allow these links to contain anything other than the PCDATA and, perhaps link-end children?
3.3.a: Should we have a type of link that tries to be a nice clean superset of HTML's "
3.3.b: If so, what should we call it?
3.3.c: If 3.2.b goes the way of child elements for link-ends, should the "A" link have a single child element for consistency with that, or no such element for consistency with HTML?
3.3.d: Should we regard such an "A" link as having one or two link-ends?
3.3.e: If it has two link-ends, is it a problem that there is no obvious place to put link-end metadata for the "implied" link-end?
3.3.f: SHould we provide a content model for "A" links?
3.3.g: Should we allow "A" links to contain anything other than PCDATA?

From section 4. Addressing

4.a: Should we make it clear that link-ends can point at a wide variety of things, and that some of the things can be plural?
4.b: What should we say about the situation when a link is pointing at another link?
4.c: Should we allow the use of addressing types other than the ones in the spec?
4.d: If we are discussing a link processor, should we require support for any or all of these addressing modes?

From section 4.1 HREFs and Reference Types

4.1.a: Should we have a single attribute used for storing all addresses, with another attribute expressing its type, as with the initial draft's HREF/HRTYPE? Note that this has the side-effect that a link-end can contain only one address attribute (which of course, could be a tokenized list).
4.1.b: If so, what should they be called?
4.1.c: If not, should we use a different attribute for each type of address? Note that this means we could in principle have multiple addresses per link-end although only one of each HRTYPE.
4.1.d: If using different attribute types, can we have multiple addresses per link-end?
4.1.e: Should we discard this scheme and adopt something wholly different for selecting among address types?
4.1.f: Should we abandon the idea of different address types and assert that everything is a URL?

From section 4.2 Location Source

4.2.a: Should we formalize at all the concept of a base address?
4.2.b: If so, should we call it a location source or something else?
4.2.c: Should we formalize the concept of the implied location source?
4.2.d: If so, should the values be DOCELEM and REFERRER, defaulting to DOCELEM?

From section 4.3 SGML Address

4.3.a: Should we support this type of address?
4.3.b: Should we support entity addressing by name?
4.3.c: Should we support element addressing by ID attribute?
4.3.d: Should we support a combination of these two?
4.3.e: What syntax should we use?

From section 4.4 URL Addressing

4.4.a: Should we support this?
4.4.b: Should we say anything about the content, use, or interpretation of the URL?

From section 4.5 TEI Locator addressing

4.5.a: Should we support this?
4.5.b: What portions of TEI locators should be dropped from this spec?

From section 4.6 Query Addressing

4.6.a: Should we support this?
4.6.b: If so, should we specify any query languages?

From section 5. Extended Link Groups

From section 5.1 Identifying Extended Link Groups

5.1.a: Shall we support a mechanism for a document to contain a list of other documents that someone thinks ought to processed with it?
5.1.b: If so, shall we say anything normative about whether this must be done?
5.1.c: Should we use an SGML element, a PI, or some other construct to hold this list of documents?
5.1.d: If we use an element, what should it be called?
5.1.e: If we use an SGML element, should we have subelements per referenced doc or just a token-separated list of entity names in a single attribute? In either case what should the subelement (if any) and attributes be called?
5.1.f: Should we specify recognition based on reserved attribute, GI, and external information?

From section 5.2 LINKS and LINKSET elements

5.2.a: Should we provide an element to serve as a corral for multilinks?
5.2.b: If so, should we require its use?
5.2.c: If we allow but not require its use, should we require that if the corral is used, there be no multilinks outside it?
5.2.d: Should we specify recognition based on reserved attribute, GI, and external information?
5.2.e: Should we specify LINKSET documents?
5.2.f: If we specify LINKS and/or LINKSETS, should we discuss the temporal effectivity and user-visibility of the links therein, in terms of the period the document is "open"?

(i)	should it be optional or required,
(ii)	should it be associated with links or allowed to vary per end,
(iii)	should it be carried in the GI, in an attribute name, or in an attribute name-value pair, and
(iv)	should we predefine a set of values, and
(v)	if so, should we provide a mechanism for "subclassing", and
(vi)	should we allow the use of values other than those predefined or subclasses thereof?