>This needs a solution that is above the character stream level and below
>the application protocol level.
....
>Were it encoded into the character stream, that would result in
>quoting problems which would destroy server-side searching
>capabilities.
Perhaps, but perhaps not. It really depends on the search engine.
>Were it put at the application protocol level it would require a
>datastructure so complicated as to be completely impractical and
>unusable.
I would say that this statement is completely inaccurate. Attribute
based-protocols all share a common data model that is very simple.
>In addition, putting it at the application protocol level means that
>a different solution for the same problem will be necessary in each
>application protocol.
I do not consider this to be a bad thing, because you can then
optimise the solution for the particular problem. Searching is a good
example: some systems might perform well searching against mlsf,
whereas others might search better with structure keys. I would say
that linguistic searching based on mslf would not be scaleable.
(i.e. asking a 1GB document the frequency of various language use
would be slow).
>There are *a lot* of attribute-value based protocols including SNMP, LDAP,
>DHCP, ACAP, RFC 822/MIME/HTTP, etc. In fact, the attribute-value model is
>a basic tool in protocol design. There's simply no clean way to represent
>language alternatives of multi-valued attributes at the application
>protocol level.
I think this is completely incorrect. A protocol is nothing more than
a set of data structures, and the encoding of them. There are
obviously a number of ways of representing linguistic alternatives in
data structures, and therefore, there are a number of data structure
encodings possible. That says to me that a number of application level
protocols are possible.
You could have just as easily designed an application protocol based
on SGML: Define a number of private use characters to be SHORTREF's,
which would expand into tagging structures like:
<TEXT><LANG EN>...<LANG FR>...</TEXT>
though I certainly wouldn't recommend using private use characters in
this way...
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT