Re: fragment exchange (was Re: rationales for TEIextended-pointer keywords)

I have been through the same problems as Rick, and I think they stem from
too concrete a view of what XML-LINK is.  I'm taking bandwidth partly to
suggest that additional background information to XML-LINK would be
extremely valuable in the July1 draft; for example, pointers to Eliot's 
XML-DEV posting (or excerpts from it).

Recent postings have mirrored some of my early misconceptions about XML-LINK -
that it was concerned with presentation, with documents, etc.  The TEI 
heredity is valuable, but may suggest that XML-LINK is primarily linked to
text documents - it need not be and I certainly intend to use it in other ways.

I think that I had hoped there would be a generic 'link-processor' in the same 
way as a generic 'parser' for XML-LANG - and the spec used to have this phrase
(I think it's disappeared?).  So I envisaged a sort of 'HyTime-lite' which
was able to be customised for various applications.  This may still be possible
but it seems like a lot of work.  I shan't write it :-)

So it seems to me that the answer to most of these questions will have to be
'it depends on the application'.  That isn't a cop-out (as it may have been for
some other issues).  It's like saying 'what do you use references (pointers)
for in Java?'

The challenge for the ERB is to give readers some idea of what the syntax is
for, whilst not predicating particular applications.  For example, I have
consistently argued against too frequent a use of the word 'text' in the 
spec, because there will be many applications with no text at all.

I suspect that 'span' arises out of textual applications with the document
viewed as an event stream.  There are many applications where span is a
meaningless concept, or when it is extremely likely that a given span would be
illegal.  

Think of the target document describing one of the following:
	- a gearbox
	- a set of molecules
	- the British Royal family
	- the London Underground

Here the links mighthave roles like:
	- meshesWith
	- isReactionProduct
	- isMarriedTo  (this is now obsolete)
	- intersectsWith

In message <199706140805.SAA29506@jawa.chilli.net.au> ricko@allette.com.au writes:
[...]
> 
> One more try. Let us have linking element:
>  <a   	XML-LINK="SIMPLE"
> 	SHOW="REPLACE"
> 	ACTUATE="USER"
> 	HREF="http://www.elsehwhere//other.xml?XML-XPTR=ID(chap1.section2)..ID(part1.section3)">

To parody this:
 	HREF="http://www.elsehwhere//other.xml?
            XML-XPTR=ID(mol1.atom3)..ID(mol5.atom10)">

This is obviously application-dependent and probably meaningless.

> I traverse that link. I understand the server-end constructs (or has) a grove for that document, and
> selects or marks (or whatever) the appropriate nodes as the resource. 
> 
Again a parody:
I am in a browser [garage]. I expect a replacement text [gearwheel].  In what 
form does the resource get back to me to 
replace my existing text [part of my gearbox]?  It cannot be XML [spans] as 
it is,  because it will not be well-formed [so I'll choose a different XML 
construct].

[...]
>  
> Yes. But the document is in the memory of the server, and I want my fragment in the memory
> of the client. What have I missed?  Is this in fact impossible in XML, and the XPTRs only
                 ^^^^^^^^^^^^^^^^^^^
What I initially missed as well :-)
That the use of spans is only possible in certain applications, and that they
have to be supported by application-dependent conventions.  Spans are probably
a poor way of passing electronic gearboxes, lines on the London Underground,
call graphs for C++ programs, etc.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

Received on Saturday, 14 June 1997 06:23:14 UTC