[tm-pubsubj-comment] Pub Sub working draft comments

[Kal Ahmed <kal@techquila.com>]

Dear all,

Below are some comments on the final draft of the Introduction + Basic
Requirements document.

Section 2.3

I understand where this section is coming from, but the argument is a
little too simplistic.

On the web, URIs do not necessarily address a resource, they might also
address a service, but the representation retrieved by dereferncing the
URI is not the service, merely the results of the service performing
some processing. c.f.
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=topicmaps

The resource is not "topicmaps" (which is what I typed into the search
box), nor is it Google, but it is the result of asking Google for pages
about "topicmaps"

I guess that my concern is that not all addresses are addressable
resources, because addresses are also used as gateways to services. I do
not think that this is something that needs to covered in great detail,
but I think that the section would be stronger if it acknowledged that
other uses of URIs are possible and that these fall outside the scope of
the discussion.

Section 2.4.2

"if the identity of two topics is established by subject indicators that
have the same address, they should be regarded as representing the same
subject."

How are addresses compared ? Straightforward string comparison is not
necessarily a guaruntee that two addresses are not the same:
http://www.techquila.com/ and http://www.techquila.com/index.html
address the same resource because of server-side processing. Similarly
typing techquila.com into my browser gets me the same resource because
of a combination of client-side and server-side processing.

XTM 1.0 section F.2.2 expresses the rules which establish when two URIs
are to be considered equal (by chickening out and pointing to the
relevant RFCs ;-). Either this specification should do the same, or else
it should include sufficient words to make it clear that address
comparison is not necesarily a straight-forward lexical comparison and
that the comparison mechanism should be dictated by the subject
indicator address notation.

Section 3.1.2

If the URN could be "resolved" by looking it up in a book, would that
meet requirement 2 ? If to "resolve" the URN you had to email the
"Keeper Of The Definitions", would that meet the requirement ?

IMHO, the resolution mechanism is only going to be useful if it is known
to those using the PSI. So I would change this requirement to something
a little stronger:

"A Published Subject Identifier must be resolve to a human-interpretable
Published Subject Indicator using a resolution mechanism known to and
accessible by the intended audience of the Published Subject
Identifier."

BTW, "a human-interpretable" sounds better to me than "an
human-interpretable", but don't ask a Brummy for advice on English (c.f.
http://www.virtualgaz.co.uk/gazzapage.htm)

Section 3.2

"Human-readable" should probably be defined more clearly. e.g. I would
suggest that comments in an HTML page are not human-readable in the
sense that they would not be displayed in the application which
implements the resolution mechanism. Also, human-readable English is not
human-readable. Again, I think that the concept of the audience of the
PSIndicator needs to be considered here.

Cheers,

Kal







----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>