[Prev][Next][Index][Thread]

Re: 1.c-d: Define a Link Processor and Communicate With It?



At 11:09 AM 1/31/97, Tim Bray wrote:
>1.c: Should we exclude relationships such as containment and
>succession from this spec?

How is this different from 1.b? Otherwise, what I said.

>1.d Should we specify a way for a document to provide a summary of
>the linkage machinery it uses?

Yes, as users need to be able to choose their options.

I think that we should _not_ have explicit leeway for implementors to vary
implementations within XML Linking. They can extend, but such extensions
should be _clearly outside_ the scope of the standard...

There's nothing to stop people from implementing new features, just as
anyone can put new tags into HTML, but they should not be able to claim
that their new feature is "part" of XML linking, unless it is universally
mandated. This is essentially the hypertext extension of the "no options"
policy goal.

In particular we have to bite the buillet and decide what address formats
are legal and not, what link facilities are legal or not. Extensions _will_
duke it out in the marketplace, but we need a well-defined, interoperable
base of functionality.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________