Re: xmllink-970406 various

 
 In message <199704070431.AAA19906@www10.w3.org> Michael Sperberg-McQueen writes:
 [...]
 > 
 > Good point.  We need a nice verb for what applications do.  Normally
 > I'd say 'process' but our distinction between the 'XML processor'
 > and the 'application' makes that untenable.  I'm pretty sure that
 > these attributes and their information are intended for exploitation
 > by apps, not XML processors per se.
 > 
 In an earlier version there was talk of a 'link processor'.  I am not a 
 hypertext expert but in hacking code it seems to me that it is possible
 to have a generic link handler (link processor) which is application 
 independent (although it might have to provide ways to an application
 to override its behaviour if this is what is allowed).  Please forgive
 me if this is naive...
 
 At present we have application-independent parsers and it seems possible
 to do the same for link processing.  The processor would act (say) on 
 the abstract tree and traverse it looking for link attributes.  When these
 are found it would take generic action.  For example if a document contains
 	<A XML-LINK="SIMPLE" HREF="foo.xml" SHOW="REPLACE" ACTUATE="AUTO">
 	<A XML-LINK="SIMPLE" HREF="bar.xml" SHOW="NEW" ACTUATE="USER">
 the generic processor would immediately replace the current tree with 
 that from foo.xml.  *how* foo.xml was processed might be application-dependent
 but would normally be determined just from the XML documents.  (Of course
 the link processors might vary in (say) keeping a navigation record, allowing
 backtracking , etc.).  [In the example above, all parts of the document
 below the first link might never be used unless there was some other means of
 jumping into them.  I'm not suggesting this is good style...]
 
 I am trying to produce JUMBO as a generic browser with functionality added
 through DTD-specific classes.  Clearly components like TEI searching are
 generic and application independent and on first glance it seems that link
 processing should (or at least could) belong to the processor.
 
 [...]
 > 
 > >However, for these three attributes it's unclear what various
 > >combinations would mean.  If an Extended has three Locators,
 > >and the Show attribute on the Locators is Embed for one,
 > >Replace for another, and New for the third, what should an
 > >ordinary browser app do?
 > 
 > I would say "If the user tries to actuate the link starting at
 > the first location, then embed; on actuation of the link
 > starting at the second location, then replace, etc."  Is there
 > really any other possible interpretation?
 > 
 > (There is, to be sure, a certain uncertainty about what can be
 > meant with Embed and Replace on extended links with, say, ten
 > locators.  To be addressed later ...)
 
 What is the uncertainty here?  (Other than perhaps REPLACE/AUTO as above?)
 Any */USER attributes correpsond to 'buttons' and wait to be pressed.  If they
 are EMBED they (might) reformat the document with a picture, rotating molecule,
 etc. inlined in the text.  If NEW they might bring up a new window.  If REPLACE
 then the first (and therefore only) button to be clicked, wipes out the 
 current document and the rest of the locators.  EMBED/AUTO means inline the
 resource whilst formatting (for example), and NEW/AUTO means bring up a new
 window with the targetted resource in it.  Of course spawning 10 new windows
 from one document, especially if *those* have similar behaviour, won't make
 one popular, but this *is* down to the application to trap (it could count
 the total number of windows for example) or conceivably to the authoring 
 tool.
 
 	P.
 
 -- 
 Peter Murray-Rust, domestic net connection
 Virtual School of Molecular Sciences
 http://www.vsms.nottingham.ac.uk/
 

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

Received on Wednesday, 9 April 1997 20:23:04 UTC