RE: What to do about namespace derived URI refs... (long)

> 2) You cannot wish away (by virture of some definiton which is out of
> channel) the fact that http://robustai.net/~seth/index.htm#Truth returns
> some sting of bits and that the URL identifies that string of bits.  It
> cannot do that and identify my Truth as the same time, without causing an
> ambiguity.


Um, isn't the return of anything or any behavior relative to a UR* a
property of the "user agent" or application.

--A UR* should point to a thing.  The only property of a UR* is that it
points.
--What things UR*'s point to in a given "document" is a property of the
specification and definition of the document.
----By implication, but not definition, the doc type constrains reasonable
interpretations of a UR* referent through socio-linguistic context.
--Interpretation of a UR* is a property of the processing application.
----Interpretation can include an attempt to retrieve bits.


So in the case of #2:

The URL points to a resource.
The RTF specification delimits what the URL points to.
Applications that get information from a RTF parser decide what the @#$%
they want to do with the specified resource.


-----------

As a rule pointers just point.  A type-safe C pointer is already enriched.

In the case of RTF, I think the pointer definition should be separate from
any options to enrich the pointer.

Options to enrich an RTF pointer with structural information should use
existing XML specs.  The pointer should be bound to an XML data structure.

Options to enrich an RTF pointer with semantic information should use
emerging RTF specs.  The pointer should be bound to instantiated RTF
productions.

Received on Wednesday, 6 June 2001 17:04:48 UTC