Initial draft of XML-Link spec now availab
It's a happy day here. :-)
For the most part, I agree with Durand. The naming issues
are a matter of taste. I can't find any terms that aren't
overloaded, so whatever. I don't generally like the use
of Latin. It's dead.
>From "section 0": Naming
>0.1 What should the title of the spec be?
XML Linking and Location Specification
>0.2 What should the generic term or acronym we use to reference whatever
> it is the spec describes?
XML - Part Deux
Don't introduce new acronyms if you can avoid it. Too many
people can't figure out why SMGL is wrong.
>Should links be expressed as SGML elements?
If this means the specification has a set of element type definitions
that are the range of the set of all XML Links, no. If this
means a link is XML is specified by the application designers
as an element type, maybe. If this means, XML provides a
set of abstract types or classes or architectural forms from
which an application designer can derive a set of element
types, or another architecture for link types, yes.
>1.c: Should we exclude relationships such as containment and
>succession from this spec?
Maybe. The concept of tree relationships as used in TEI
is quite good. Previous and Next confused me originally
until I read Lou's paper. Like most of the world, I thought
these were file/frame load semantics as On The Buttons.
>1.d Should we specify a way for a document to provide a summary of
>the linkage machinery it uses?
No. This is an application design decision. An informative
annex may include a recommended way to do this. On the other
hand, this depends on how the XML specification is treated.
As "a set of recommendations", there is no normative text.
As a standard, such separation is needed. Should this ever
move to ISO, it is probable such a separation would be performed.
OTH, if by this, a CATALOG is meant, then I favor that as a
separate specification. It's utility is undeniable.
>1.1.a are formatting issues (aside from perhaps a metadata slot)
>outside of scope?
Yes. But defining all linking to be formatting is a red herring anyway.
A link to an executable (done every day) is not a call to a rendering
>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?
If writing it as BNF is clearer, do that. I am satisfied with SGML.
If you do BNF, do both.
>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?
If a link does not fit into an XML document, what good is it?
However, an application designer declares what fits into an XML
I probably don't understand that question.
>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.
Send Jon a bottle of aspirin and some antacid to the rest of us.
>1.4.a What do we call the container used to hold the bits that
> point at other things? (in current discussion: link)
>1.4.b What do we call the bits that point at other things? (in current
> discussion: pointer)
Pointer is OK. I believe it will be confusing too. This seems to fall
under the "more meta than thou" dilemma.
>1.4.c What do we call the things that are pointed at? (in current
> discussion: terminus)
Latin is dead. Requiescat in pacem. Target is easier
to use. Confusion with HTML is not a problem. But, I don't really
>1.4.d: What do we call the locator/adddress?
>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?
clink and ilink. Why use anything else when you can use a standard?
>1.4.e Should we get into talking about bi/multi directional links?
Yes. I like n-way links. No protests from the Swingonics Task Force.
>1.4.g Should we define/discuss traversal?
Only if you can make it simpler than the discussion in ISO 10744.
This one deserves graphics. Will a discussion of traversal
include state management, IOW, is is affected by the candidate
The problem here is that if discussed, you must be very explicit
about how the concept of traversal is used: lots of examples.
>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?
This comes back to the concept of architecture and letting
a link inherit from multiple architectures. If as in
HyTime, XML Linking ONLY defines the minimum/basic architecture
which all XML applications share, no. If yes, would this force
a breakout of subtypes beneath XML and complicate MIME typing? If a
XML application equals a notation, and that notation can
be declared to the XML processor invisibly to MIME,
then, the handling of XML applications is a separate problem
and XML Link does not require all of the above because
they can be added by the application designer.
This really depends on how much portability (data declared) and
interoperability (predictable behavior in the sense of a virtual
method/message) you want. You can have portable data easily
using the syntax. Interoperation is behavior by definition and
this cannot be shared unless you have a communication protocol
which includes the values you want to include in a message.
To me, this falls inside the application domain. In other
words, is a link a data object or a data structure?
>1.c Should we define a link processor and specify any actions
> required of it?
See above. It is the most effective way to get interoperability.
OTH, this looks like application design. We may want to consider
this in terms of a reference implementation.
>During the ERB meeting, my esteemed Co-editor pointed out that a word
>that is synonym for both "target" and "end" is... "butt". So instead of
>termini, we could have butts. Multi-butt links. Butt modes. Butt
>syntax. I like this. -Tim
I guess if you put all the links in the header you would then
have buttheads. I like that too. Heh Heh Heh.