Re: xmllink-970406 various
Terry Allen wrote:
> Michael re Gavin:
> | >Right, and this is the core of my disagreement with using queries.
> | >We either standardise something, or nothing will be gauranteed to
> | >work, in which case, it's probably better to stay silent for the
> | >moment.
> | This appears to be an argument which proves that queries IN GENERAL
> | cannot possibly be useful -- nothing specific to XML here. Since
> | queries do in practice seem to be found useful, despite the fact that
> | they only work on servers on which they work, I don't see any reason
> | not to describe how they can be used in XML. The same problems
> | surely arise if you build the query into the path segment of the
> | URL: it will work only on servers on which it works.
> | What am I missing?
> Nothing, you said it with "nothing specific to XML here". You want
> (reasonably) a facility that URLs don't provide yet, to wit,
> fallback to fragment-ID behavior if the query isn't understood.
> Or you want to instantiate a (one among many) standardized query
> language in URLs at least to the extent of being able to declare
> what it is.
> The solution is to ask for it of those responsible for URLs and
> perhaps HTTP.
This doesn't jibe with my understanding of URLs, HTTP and the
specifications which standardize them. My reading is that
they provide a *placeholder* for queries, but don't define
them. It is the responsibility of those who specify the
client user agent to do this. I may be confused on this point,
but it also appears that a complete instance is always returned
and the user agent must resolve the query. If so, then the
point would be for those defining clients to support the
specified query language, not the URL or HTTP specs or specifiers.
Many would like server side support
such that fragments (gotta use the term SGML Open defines here)
are returned. This has been an obvious and real need in
SGML systems for a long time. The work I have done in the
area of IETMs indicated to me at least, that the query was
the best solution to the user and management interfaces to
highly dynamic data. High dynamism is the hallmark of
concurrent integrated development environments. Where the
enterprise is large, the product complex, and the developers
are geographically distributed, stored queries are vital
to coping with the dynamic aspects of workflow. This isn't
the place to get further into this, but I assert the requirements
are quite real and should not be held back by the slow moving
evolution of the WWW protocol standards.
So, even if there remains much definitional work to be done,
I must side with Michael and argue that at least a default
query language and behaviors should be defined for XML at