Re: Can we be more concrete?

W. Eliot Kimber wrote:

> That would be the semantics of Crossref and/or the refsub anchor role
> and/or the data addressed by the query and/or whatever the browser chooses
> to do.  The semantics could be defined in the XML link spec or in a style
> sheet or some combination thereof.  Certainly XML could provide attributes
> for hinting at the desired behavior if we felt that was appropriate.

As the year closes, what is looks like from here:

1.  Ilinks - yes (spec to be defined).  Links can point out 
    to ilinks and ilinks can point in to "non-aware" content.
    Ilinks can be in separate documents where they effectively 
    work as catalogs of relationships.  Policy for the accessing 
    of an ilink is application-specific or separately standardized 
    just as policy for the access of ANY content is a management 
    policy for a server-owner. (you can hit some sites as often 
    as you like.  without the password, no washee).

2.  Semantics - per application ??  An <a is an anchor because 
    the application designer says it is.  Only the hairdressing 
    code knows for sure.

3.  Behavior - per application ??  Stylesheets or any processor 
    spec could be used.  Application conventions for XML applications 
    can be defined, but these differ little from other tag registry 
    concepts (hints with a bite).

4.  XML does not define location protocols.  Any location address 
    scheme specified within the spec must be resolvable within the 
    existing WWW location protocols.  To understand the limits of 
    this approach, it is necessary to completely understand the limits
of 
    a URL.

These look to me a lot like SGML-with-simplified-syntax and application 
conventions.

I am still inclined that:

A. The XML advanced hyperlinking portion of the XML
spec/std/CarvedOnDoor 
  should be separate with regards to conformance from the XML syntax 
  with regards to locator types.

We could just point to ISO 10744 or TEI but that is not a solution 
likely to get consensus.  IMO, the arguments appear to me to be among
twins 
arguing over the attractiveness of a birthmark only one of them has.  We
can specify a minimal set of locators in our own syntax but these will
probably still be subsets of the ones offered.  Various approaches to
specifying these have been offered.  

The TEI and HyTime approaches are the 
best understood and have been worked the hardest by their 
supporters.  If a combination of these reduced to the most 
useful types were proposed with an appendix advising how these 
can be implemented using an IDL syntax, I believe a very saleable 
proposal 1.0 could be offered. [Note:  the IDL is requested only 
to show a programmer what is intended without requiring them 
to first learn SGML, XML, HyTime, DSSSL simply to understand 
the intent of the design.  Further, this could be invaluable 
to other parallel standards efforts.]

B.  The stylesheet/processor spec should be separable.

The existence of alternatives to DSSSL must be acknowledged.
While this phase of our discussion was supposed to be last, 
it keeps emerging in the form of a processor specification
for hyperlinking behavior.  We can't have it both ways.  It either 
is or is not on the table right now.

The problems with HyTime and the problems with DSSSL on the 
surface of the discussion seem to be the same problems.  Both 
are unfamiliar to the majority of the intended audience, and 
both are unproven except in scattered applications.

Now, if the Technical Corrigendum produced the intended alignment, 
there should be no overlap, and there should be a perfectly obvious 
way to use these together in XML.  I think the proposal that 
does this should be the most worthy candidate.

len

Received on Monday, 30 December 1996 21:42:49 UTC