Re: xmllink-970406 various
| > 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.
In that case the effect of using # or ? is the same, and there's
no particular need to specify how to use ?. As in practice,
gets you Robin Cover's SGML Web Page, and
"SEARCH program (www_root:[bin]wwwsearch.exe) not found."
it would appear that ? is unreliable. (That was my quick
test; are the results anomalous?)
| 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.
I agree with the first part of that, but I don't see how we can not be
held back unless we are willing to specify XML-compliant server
| 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
| this time.
Which implies conformance language, and its being binding on
servers, doesn't it?
Terry Allen Electronic Publishing Consultant tallen[at]sonic.net
Davenport and DocBook: http://www.ora.com/davenport/index.html
T.A. at Passage Systems: terry.allen[at]passage.com