Re: 1.c-d: Define a Link Processor and Communicate With It?
At 6:29 AM 2/1/97, Martin Bryan wrote:
>>1.c: Should we exclude relationships such as containment and
>>succession from this spec?
>No - We need concept like PARENT, CHILD, HERE and ROOT to make querying into
>documents that do not have any IDs or otherwised named anchor (or whatever
>they are called) points.
An interesting point. This would allow XML linking to externally attach
markup to non-XML data. While I like the idea, and have specified such
markup in projects that I'e worked on, I'm not sure that XML can't live
I agree that it would be good if we had it though....
>>1.d Should we specify a way for a document to provide a summary of
>>the linkage machinery it uses?
>If we can have a way of identifying the notation used for link definition,
>with ideally that notation pointing to the address of a Java class that can
>be used to implement the relevant notation, then we might be able make it
>possible for blind browsers to process newly invented notations.
And _impossible_ for blind users to use those notations, because they
invoke a bunch of AWT crap-code that can't be interpreted (turing complete,
don't you know), and whose execution is pointless.
This is one of many reasons that executable specifications must be
applied _after_ a declaration of type (And to effectively require the type
declaration, we need to make it part of attaching the processing spec,
since most people don't look far enough ahead to see that other renderings
may be appropriate.
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________