[infod-wg] Notes from INFOD specification review 9 December 2005
Susan Malaika
malaika at us.ibm.com
Thu Dec 8 14:38:29 CST 2005
Please let me know if you have comments on these notes:
Intefrace Specification Review Session
https://forge.gridforum.org/projects/infod-wg/document/INFOD_Interfaces-draft/en/12
Attendees:
Stephen Davey, Steve Fisher, Dieter Gawlick, Chris Kantarjiev,
Cecile Madsen, Susan Malaika, Shaleindra Mishra
Apologies:
Vijay Dialani
Actions arising from Chris Kantarjiev comments - All these actions will
be reported on - on the call on 22nd Dec:
ACTION for Cecile: Make Section 3 naming consistent with Appendix supplied
by Shailendra.
ACTION for Dieter: Make section 2 consistent with section 3.
ACTION for Stephen Davey and Chris Kantarjiev: Complete the object model
for INFOD and place on gridforge (to help with XML generation, to
understand what we are talking about in the use cases, to cross check the
interfaces in the use cases)
Actions from Steve Fisher and Stephen Davey comments
ACTION for Dieter: Cleanup headings in accordance with Steve
Fisher remarks
ACTION for Dieter: Remove all items that should not be
mentioned in the base document (e.g., POBoxes, and Disseminators which go
in a white paper or advanced specification) - Do global search
ACTION for Dieter: Merge references for use case and patterns doc
ACTION for Dieter Page 4: Define and explain vocabulary
on page 4 when it is first mentioned
ACTION for Dieter Page 4 typo - last but not least,
associations and relationships
ACTION for Dieter Page 5: Identify the requirements that
are not satisfied in this specifications (keep the whole set of
requirements)
ACTION for Dieter: Remove non-goals
ACTION for Dieter: Page 7 - Four kinds of objects -all
have EPRs : (1) entity, (2) vocabulary, (3) vocabulary instance, (4)
association
ACTION for Dieter: Avoid font smaller than 10 - also
remove color - - (see figure 3)
ACTION for Steve Fisher: Page 7 - par 1 - Send Dieter
paragraph to clarify: whether vocabulary is compulsory or not
ACTION for Dieter: Remove publication type and home
disseminator
ACTION for Cecile and Shailendra: Review register
vocabulary and version issues
ACTION for Dieter: Remove the word important (see Steve
Fisher notes below)
ACTION for Dieter : Page 7 - sort out vocabularies -
introduce sub-section between 2 and 2.1 (see Stephen Davey notes)
ACTION for Dieter: Page 7 - delete register vocabulary as
it is covered in Section 3
ACTION for Dieter : Review 2.1 and 2.1 because a lot of it
is covered in Section 3 (so section 2 becomes overview)
ACTION for Dieter - Suggestion from Steve Fisher -
consider the hybrid XML and BNF notation used in WSN
-------> Break for Flapjacks
ACTION for Dieter: Clean up section 2 (use prose not
bullets) and remove references to names with INFOD_*,, EPR,
ACTION for Cecile: remove Pause and ResumePublisher
operations from Registry
ACTION for Steve Fisher: To check why operational issues
action item has been closed
ACTION for Cecile: Change getMData to getMetadata
ACTION for Cecile: Have another go at re-writing the
paragraph p18 for the Consumer operation
ACTION for Cecile: Remove Pause/Resume Consumer
ACTION for Cecile: Update all create operations with the
description '... is used to create an infod xxx entity in the infod
registry' instead of spitting out 'the infod consumer creates... itself'.
so removing the 'role' of the person issuing the create operation
ACTION for Shailendra and Dieter: investigate the need for the
publish interface on publisher and description of publishing (wsn doesn't
- as it relies on soap by default)
ACTION for Cecile: In 3.2.1 to have the full the full xml from
the appendix for at least create publisher (o that other sections can
refer to it and only have sub-set of the info)
ACTION for Cecile: Page 40 - INFOD Entity and another INFOD entity
(see Stephen Davey notes below)
ACTION for Cecile: Implement changes in her reply to
Stephen Davey below
Chris Kantarjiev
I started my review by drawing UML for the interfaces. That's uploaded
(into the
same file as the car dealer sequence diagram I mentioned yesterday) with a
partially populated object model that mostly matches the current spec.
I'll have more specific comments in the next few days, but I'll remark
overall
that the spec is very inconsistent in terms of naming conventions,
capitalization conventions, and references between sections 2 and 3. In
particular, since we're defining a wsinfod namespace, why do so many
things
still begin their names with infod?
The whole object/entity/message/interface distinction space is *very*
clouded in
the spec. Trying to draw this up makes that painfully clear. I'm not very
good
with UML; I'd be tickled if someone would look at what I've done, even at
this
early stage - I'll continue to work on it.
chris
.................................................................................................
Steve Fisher
Comments on
https://forge.gridforum.org/projects/infod-wg/document/INFOD_Interfaces-draft/en/12
i.e. version 12 of the spec
--------------------------------------
One general problem is that it does not properly reflect that fact
that this is supposed to be the INFOD base specification.
This requires an change to the title to include the words "base
specification" and a version number which will be 1 when it finally
goes out. Compare our title with the most recent GGF doc:
http://www.ggf.org/documents/GFD.56.pdf
The cover page should say GWD-R not I and it should be clear that this is
a recommendation document. See:
http://www.ggf.org/ggf_docs_process.htm
for the requirements and GFD.56 as an example
The last para of the abstract is not approriate for this kind of
document - I would just drop it.
All diagrams should avoid colour.
All mention of PO boxes and disseminators must be completely removed
from this document - there should be no forward reference to a
companion specification.
On page 4 we also say that consumers can specify what is considered to
be an event. This does not belong in the base spec. I don't think we
have the intelligent cloud in the base spec either.
There are references to INFODU and INFODPAT - did we not agree to merge
these?
On page 5 we should probably only list those requiremnts met by this
spec. Or at least we should amrk clearly those which we don't address.
Page 6. I think we should drop the non-goals section. If people have
not even consider that INFOD might cover these areas it will just add
to confusion.
Page 7 and beyond. It is still not clear if we have INFOD objects as
well as entities and precisley how they defined (if they both exist)
Page 7 says user vocabularies have to be defined by INFOD users. And
in the next sentence "user vocaularies are optional". Both statements
cannot be true!
Page 7 defines vocabulary associations. Is this statement only corretc
for user data vocaularies?
Page 7 the semantics of altering (and deleting) vocaularies needs to
be thought through and described. Maybe it has been thought through -
but it certianyl has not been described.
Page 9 When you add a version do you get a tree of versions? When you
deregister do you delete a node - can it be a non-leaf node or do you
destroy everything?
Page 9 2.2.1 refers ro "important" information - drop the word "important"
Sorry I have not got much done - I will continue on Monday.
Steve Fisher
................................................................
Stephen,
Answers to your questions...
Thks,
Cecile
--- Forwarded by Cecile Madsen/Santa Teresa/IBM on 12/08/2005 08:48 AM
-----
"Stephen Davey" <sdavey at nesc.ac.uk>
Sent by: owner-infod-wg at ggf.org
12/08/2005 05:29 AM
To
<infod-wg at ggf.org>
cc
Subject
[infod-wg] notes on the INFOD spec
Hi there,
While I was doing my use case and sequence diagrams there were a few
things that I was unsure about or didn?t understand in the INFOD spec:
1. How do you find/list/discover vocabularies already in the INFOD
Registry? Is it by using GetMData?
- that is the only mechanism now, as we don't have 'list' functions
2. I got a bit confused about the difference between user property vocabs
and user data vocabs and the sentence
?/vocab:Type Required. One of 2 values: ?INFOD_Property_Vocabulary? or
?INFOD_User_Vocabulary?.? mentioned in section 3.6.1. Should the type
INFOD_User_Vocabulary be replaced by INFOD_Data_Vocabulary?
- yes user vocabulary = data vocabulary - inconsistencies should be fixed
- user vocabulary allows subscriber to define the subscription predicates;
property vocabulary defines terms and
properties about a particular infod entity (like for ex a consumer)
3. Perhaps in section 2 you should describe *why* you need to distinguish
between property & data vocabs.
- ok
4. Also in section 2 (at the top of page 7) you say ?INFOD vocabularies
are XML schema?, but then you say user data vocabs can be non-XML. When
you register a vocabulary do you need identify that it is non-XML?
- not addressed yet but we should
5. When do you need to create vocab instances? Is this when you want to
populate your inventory?
- as in the car ex, a vocabulary for car dealers is a template,
pre-defined; a car dealer registers itself to the domain of car dealers by
creating a vocab instance for it (provides its own specifications); that
way, the car dealer
when it defines itself as a 'publisher' can associate to that publisher
info the specific vocab instance just created. It is just a way for
publishers to advertize in a common language/vocabulary what they can
do/who they are.
6. Can a subscriber (or a publisher) add a consumer to the INFOD Registry?
- should be ok. We haven't addressed authorization issues and INFOD model
doesn't restrict anything itself
7. How do you specify the consumers for a particular subscription? Is this
where the entity associations make an appearance?
- in infod, a subscription is just a query, a request. So yes, the only
way to associate another entity to the subscription entity is to use the
association
8. There is a typo in the first paragraph of section 3.7.1. It keeps
mentioning user data vocabs, whereas it should talk about associations
between an INFOD entity and other INFOD entities.
- you're right. this will be fixed.
I wonder if some sort of generic example (perhaps as an appendix) might be
useful in order to describe how all the bits can fit together and in what
order you would typically do things e.g. create vocabs, define publishers
& subscribers, add consumers, etc. This might become apparent to people if
they also read the use case document, but they might not want to go off to
another big document to try to find the info.
I had the following steps in my use case and I would have thought that
they would re-occur quite commonly:
1. Create vocabularies.
2. Register the vocabularies with the INFOD Registry.
3. Add Publishers (with a policy defined to ensure that it is notified if
any new associations are added that relate to subscriptions and
consumers).
4. Add Subscribers to the INFOD Registry.
5. Add Consumers, identifying their roles and characteristics.
6. Add Subscriptions to the INFOD Registry.
7. Create Associations between the Subscription entities and the Consumer
entities. (Publisher will be informed that this new association has been
created.)
Cheers, Stephen.
----------------------------------------------------------------------
Stephen Davey, NextGrid Software Architect,
National e-Science Centre,
15 South College St., Edinburgh, EH8 9AA, UK
Tel: +44 131 6 509820
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0003.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0004.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0005.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0006.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20051208/763e6890/attachment-0007.gif
More information about the infod-wg
mailing list