[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20030602.docuploaded
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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]