From: Lloyd Rutledge (Lloyd.Rutledge_at_cwi.nl)
Date: Wed 22 Jul 1998 - 04:37:47 CDT
On Tue, Jul 21 1998 "Dave Millard" wrote:
> However, we also believe that this is basically a continuation of our
> efforts to investigate existing standards (which we agreed to do in
> Pittsburgh). Although there is an overlap between the objectives of the
> XML'ers and ourselves we must not lose sight of our own goals, that is the
> definition of a generic location specifier for use with OHP-Nav.
> We are more then happy to promote OHP ideas! At the same time we see W3C's
> XPointer and OHSWG's LocSpec as separate efforts but do not wish to draw a
> line between them ;)
I agree with this statement and the way this discussion thread is progressing ... hopefully without seeming too out-of-sync with what in retrospect is at points an embarrassingly hotly worded Web-frantic posting of mine in this thread yesterday. OHP-Nav and LocSpec goals should affect XPointer, and certainly not the other way around. Our involvement, as described above, would fit in well with Doug Engelbart's description of A, B and C level involvement by bringing all the valuable research that's being going on in HT for decades into the arena of widespread implementation. The community has done and does important thoughtful research, and our task with OHP-Nav and LocSpec is to send it through the C-B-A chain to where it gets a lot of use, but used as it was intended.
The Web is the arean in which it would get by far the most use. Having something work on/with the Web can mean a lot of things on many levels. On one level, there is (or has been) an XML version of the OHP-Nav interaction, defined by a DTD. This gives us full control over the semantics, and XML is used as a syntax specifier with publically available validators and parsers with APIs for implementations. XML/Web is used here as a non-invasive carrier of this group's goals -- an application layer implementation that is parallel to conceptual layer goals.
Perhaps XPointer, or whatever it turns into, can be applied to OHP-Nav in a similarly non-invasive way. And there are different levels as which this can be done. We can
The feasibility of C and D are clearly debatable and cannot be fully measured until the progression of XPointer is better understood. C is most likely out of the question: our influence over the WG wouldn't (and shouldn't) be that strong, and the goals of XPointer and OHP-Nav, as said, do not line up that perfectly.
D is an approach taken by groups currently involved with XML-related W3C activities. A format supplies a means of specifying a collection of semantics. Tools come out that uniformly process these semantics. Individual efforts define extensions of formats that can uses these shared tools with extra implementation over them. The issue of extensibility comes up in SMIL, for example, where some developers may want to add their own additional pet functions but still want their documents processed by general SMIL systems. The current W3C namespace activity could develop into a formal solution for this, and have been suggested as such, though their main goal is something else. Other informal or XML-subset-specific solutions sometimes come up as well. D could be a possibility for us if XPointer is defined in a way that allows for our own graceful extensions. Public XPointer tools could still be used for much of LocSpec processing. Someone could develop LocSpec extensions for these tools, and their effort would be minimized by the existence of these tools.
Still D depends on
Namespaces as a specific solution for extensions here would not work as they're currently discussed because they apply only to XML syntax and not to more general BNF-defined string attribute value syntax such as the current XPointer. However, it is in the spirit of XML-related work to enable graceful extensibility, often at the insistence of WG members who frequently have their own functions they wish to include despite W3C. Perhaps would could influence the XPointer WG to have an extension mechanism we can use where XPointer falls short of answering our needs.
Of course this depends on our not deciding to just follow B or A or something even less involved with XPointer. We'll have to see how XPointer and our chosen involvement with it progresses.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:03 CDT