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 
engine.  

>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
application.
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)

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
care.

>1.4.d: What do we call the locator/adddress?

Locator

>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 
BEHAVIOR attribute?

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.

Len Bullard
Lockheed Martin

Received on Monday, 3 February 1997 11:32:41 UTC