There's one slight misunderstanding I should comment upon.
Contrary to your reading, a key partition as defined in this context does
include all of the keys in the key partitions derived from it. To be honest, I
prefer your take on the matter, because it clarifies the question of whether the
owner of a "parent" partition can publish keys from a "child" partition (terms
used loosely, but I think comprehensibly) - the answer is NO, they cannot
publish a key from a child partition until they have published the key generator
for the child partition (said key generator belongs to the parent partition, and
so is a permissible publishing). So a child partition is a proper subset of the
parent partition, not disjoint from it, in the current intent. Perhaps another
way of defining the current key partition is as the set of all keys that can be
derived from a particular key generator, both directly (keys which can be
published by the owner of this key generator) and indirectly (keys which can be
published by the owners of key generators derived directly and indirectly from
this one).
The more I think about it, the more I like your interpretation :-) It will
require some rewriting of the technote (which we already planned, and for which
your notes will prove useful, thank you), and may have an impact upon the
language of the spec - I think we should look carefully at that.
There's a second small misunderstanding, too. The section that describes a
way to control keys is not prescriptive, but describes a formal way in which
keys might be controlled. It is possible that a registry may adopt a looser,
less formal, approach, in which case the Green division of the Widget
corporation may well be permitted to publish their own key generator - in the
less formal approach a publisher only requires an out-of-band "permission" to
publish a key generator (I don't like this, but it matches how some
implementations operate, I gather). Only when the publishing of key generators
is tightly controlled do we require the key to be published by the owner of the
partition in which it lies, and then transferred to the publisher desiring
it.
Thank you for your critical reading of the technote - a new set of eyes is
invaluable at this stage, and can help improve the document substantially.
Tony Rogers
-----Original Message----- From: Katharine Jagger
[mailto:KJAGGER@uk.ibm.com] Sent: Fri 31-Oct-03 10:08 To:
uddi-spec@lists.oasis-open.org Cc: Subject: Re:
[uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.doc
uploaded
Hi
I have studied the parts of the spec relating to
uddi keys closely, and so I read with interest the draft Technical Note on
Understanding Key Partitions.
As someone who is reading the TN from
the perspective of an implementer rather than a spec writer, I thought my
comments may be of some use to you.
As a starting point to
understanding uddiKeys, I found the spec sections 4.4.1 "Recommended
syntax" and 4.4.2 "Examples of keys" an excellent introduction to what a
uddiKey actually looks like and what the format of a valid uddiKey
is. May I suggest reproducing these sections in whole or in part at
the beginning of the TN, so that, as section 1.2 "Background Material" of
the TN states, a publisher does not have to read the specification first in
order to understand the TN?
Following on from understanding uddiKey
formats to understanding their partitions, I found section 5.2.2.1 of the
spec a clear, succinct description of partitions (I understand CR027
clarifies this further) that followed logically on from sections 4.4.1 and
4.4.2. Could this be reproduced in place of the explanation in
section 2.1 of the TN and the corresponding diagram, which I am afraid to
say did not make any sense to me even though I am familiar with the spec
sections on uddiKeys?
Comments on Section 2.1.1 "Set
Theory":
Lines 120-124: The mathematical definition of a "partition"
of a space X is a set of disjoint subsets of X such that their union is all
of X. The spec uses the word "partition" slightly differently (though
acceptably), to mean a single one of these disjoint subsets of the whole
key space. Thus by definition one key partition cannot be a subset of
another key partition. Hence there are only two possible
relationships between key partitions - they are the same, or they are
disjoint. See section 5.2.2.1 of the spec for a definition of a key
partition as "non-overlapping and hierarchically arranged."
Line
123: A proper subset S of a set A is in fact a subset of A such
that there is at least one element of A that is not in S. (A set is
wholly contained within itself but is not a proper subset of
itself.)
When illustrating the hierarchical nature of key partitions,
may I suggest using an analogy of a directory structure instead of
subsets? A directory structure is something anyone reading the TN
would be familiar with, though perhaps not everyone is familiar with set
theory. A directory (minus its contents) is then analagous to a
keyGenerator, and files within that directory are analagous to keys with
the partition of that keyGenerator. The immediate contents of the directory
then make up the key partition. A directory itself is a member of the
directory above it in the hierarchy, in the same way as a keyGenerator
belongs to the partition of the keyGenerator above it in the
hierarchy.
Comments on Section 2.1.2 - "In Terms of String
Matching"
Lines 137-140: The colon is in the wrong place - it should
read: "Every key of the form A:x, for any non-empty string x that is not
the string "keyGenerator", lies in the key partition of
A:keyGenerator." However this is in any case rendered incorrect when
the definition of a key partition is corrected to exclude keys in a
sub-partition.
Lines 141-143 are also incorrect in that they allow the
key "uddi:tempuri.com:exampletwo" to be in the
partition "uddi:tempuri.com:example:keyGenerator" (replacing "A"
with "uddi:tempuri.com:example" and "B" with "two").
Line 144 - I
have not seen anywhere in the spec that the
key "uddi.tempuri.com:example:keygeneratorthatisnotreallyakeygenerator"
is disallowed.
Comments on Example 2.4.1
Lines
234-237: Green division cannot publish this tModel. Widgets
Inc must publish it and then transfer it to Green
division.
Comments on Section 2.2.3 "A way to control keys using
the UDDI APIs"
As I understand it there is a clear registry policy
point "Registry Key Generation" that states "The registry defines a policy
for whether and how a given node or publisher is allowed to register a key
generator tModel." Thus, in the same way that the registry must decide by
policy who may publish data in the registry, it must decide by policy which
of these publishers are allowed to publish key generators, and domainKey
key generators.
As suggested in the TN, one possible way this policy
may be implemented would be to decide that only an "administrator
publisher" can publish domainKey key generators, and these are then
transferred to individual publishers. However, this seems to
introduce an extra layer of administrative overhead, in that presumably a
publisher must first register with the registry, and then subsequently must
ask the administrator (out-of-band) to publish a key generator and transfer
it to them.
A simpler way to implement this policy would be to let the
registry (or administrator) decide at the time of the user's registration
whether or not they may publish domainKey key generators. This would
reduce the administative steps required from two to one, and once a
publisher had registered they would be able to publish a domainKey key
generator straightaway.
Of course, the point of having certain
things left to registry policy is that the implementation of a particular
policy is a matter of choice. Which (if any) of the above two approaches is
chosen is a matter of policy - the TN seems to be mandating which should be
chosen and this does not leave any
choice.
Regards,
Katharine
Jagger.
----------------------------------------------------------------------- Katharine
Jagger - Software Engineer Sun Certified Java Programmer Web Services
Development MP 208, IBM Hursley Time Zone: as London (currently GMT,
EST+5, CST+6, MST+7, PST+8) Office location A4133; Tie line:
7-245196 -----------------------------------------------------------------------
bellwood@us.ibm.c
om
To:
uddi-spec@lists.oasis-open.org
cc:
31/10/2003 14:21
Subject: [uddi-spec] Groups -
uddi-spec-tc-tn-understandingkeypartitions-20030602.doc
uploaded
The
document uddi-spec-tc-tn-understandingkeypartitions-20030602.doc has been
submitted by Tom Bellwood (bellwood@us.ibm.com) to the OASIS
UDDI Specification TC document repository.
Document
Description: Key Partitions TN Updates from 11/03 FTF
Download
Document: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/4076/uddi-spec-tc-tn-understandingkeypartitions-20030602.doc
View
Document Details: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/document.php?document_id=4076
PLEASE
NOTE: If the above links do not work for you, your
email application may be breaking the link into two pieces. You
may be able to copy and paste the entire link address into the address
field of your web browser.
To unsubscribe from this mailing
list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php .
To
unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.
|