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

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



Tim Bray wrote:
> 
> At 11:50 AM 31/01/97 -0800, Tim Bray wrote:

> >1.c Should we define a link processor and specify any actions
> > required of it?
> >1.d Should we specify a way for a document to provide a summary of
> > the linkage machinery it uses?
> 
> 1.c
> I am sympathetic to Durand's position on this one; I'd like to be as
> pure as possible about specifying simply a way to point at things.  On the
> other hand, Len's point that the market will demand some behavior
> specification has weight.  

The situation that troubles me is not what they demand, but that they 
may put one in anyway and then the horse is dammnably difficult to get 
back into our barn.  We keep getting caught on the problems of 
making information portable while keeping systems interoperable, so 
maybe we just have to say, XML does not do interoperability except 
insofar as two communicators agree to use the same processor
specification.
If an XML designer chooses to hand off property values inside the 
XML instance which are then interpretable as behavioral flags, so 
be it.  Any XML processor that can handle it does.  One that doesn't
can't.  Finis.  That is the situation with SGML/HTML now.

>For the moment, I will argue for *no*
> processor specification; simply markup syntax, and the minimum of that.

I'm sympathetic too.  Does this mean no "get" or "post"?  No action=?

If this appears contrary, bear with me.  I simply want to cook every 
potential red herring at this fishfry now before the next events in 
the public begin.

> 1.d
> On the other hand, having written 1.d, it was obvious to me that this is
> a hole in the spec.  It is of obvious utility for there a way for a document
> to signal what it's got.  I think that (a) this should be in a PI and
> (b) it should be required to come before the first element.  Having
> said that, we can defer the argument over its syntax and contents until
> we've hammered out what things XHL will do that might require signalling.

I'm only worried that we get a very long list of PIs.  It is the lesser
evil 
I guess.

len


Follow-Ups: References: