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
These look to me a lot like SGML-with-simplified-syntax and application
I am still inclined that:
A. The XML advanced hyperlinking portion of the XML
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
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.