« Return to Thread: questions on RSpecs from GEC2 meeting
Re: questions on RSpecs from GEC2 meeting
by John Wroclawski
::
Rate this Message:
Hi Jeff,
At 5:54 PM -0500 3/3/08, Jeffrey Chase wrote:
>
>It seems to me that there's a larger core question here that came up
>about the role of rspec as a language (format?) for representing
>information about resources and slivers in the GENI architecture. How
>do we balance the tension between standardization and extensibility?
It seems worth it to take a minute to frame the context here.
This data structure, whatever you call it, is the key boundary
interface between manufacturers of GENI components, who have to
create them, and the rest of the system, which has to use them. NSF
is eventually proposing to do competitive procurement of $300 million
or so of such components, from formal requests for proposals (which
means well formed specifications), from any number of different
vendors. NSF is also trying to be open to donations of useful
resources (eg, satellites, what have you) from other folks who might
be willing to make them available if they could figure out how.
It is, in my view, a very basic goal of the design that as many of
these components work with as much of the rest of the system as
possible. To make this happen, two things would seem to be true:
1) The design should encourage as much common understanding of what
an RSpec *means* as possible, across different communities,
components, component manufacturers, service creators, tool builders,
and researcher/users - so that we get as much interoperability as
possible, and so that it's as easy (and useful) as possible for a new
component vendor/creator/whatever to add themselves in.
2) The RSpec specification itself has to be as *clear* as possible,
so that random folks can figure out what the heck is going on.
To my mind this argues for as much standardization - or maybe I
should say "agreement" - as we can. If I thought there was any way to
do it, I'd argue that GENI would be best served by a standard
*non-extensible* RSpec, which would at least create some chance that
everything would work with everything else.
But of course that won't work.
So, as you say, we're looking for an extensibility model that
balances these things. I would say it as "an extensibility model that
encourages as much commonality as possible, but still allows for
evolution and change".
Now, in fact, Ted & Rob's talk yesterday outlined a "two-step"
extensibility model - although I agree it went by very quickly. The
main properties of this model are
a) An "object/subclass" flavor, so that, for example, if you have a
new sort of router with unique parameters, you can describe it as
such, and people who understand your parameters will get them, while
others will still understand it as a "router".
b) Within the XML container there are two (at least) levels of
extensibility - call them "private" and "standardized". You're free
to do anything you want with the private namespace - if it made sense
to you to put in a private attribute called "SensorML-Desc", noone
would stop you, although it might have to work as a request format as
well as a description format.
c) We imagine some process - to be clear, *not* the CFWG, since it
has to survive into the construction and operational phase of GENI as
well as the design phase - that would be responsible for elevating
new description attributes from the private to the standardized
namespace. You could also imagine intermediate "sub-community"
processes that would elevate attributes from the private namespace to
a level of shared agreement across some community of interest, such
as sensors. But other than its existence, nothing about this process
has even been proposed yet, let alone defined.
>http://www.science.uva.nl/research/sne/ndl). We should at least ask the
>question of whether we can get where we want to go in some other way,
>e.g., by extending NDL.
IMO this is sort of an orthogonal issue - if there's an existing (and
fairly community-neutral) format that we can build on to meet the
objectives above, we certainly aren't precluding it. We've already
swiped a lot of existing stuff for interface descriptions, etc. etc.
Cheers,
John
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
At 5:54 PM -0500 3/3/08, Jeffrey Chase wrote:
>
>It seems to me that there's a larger core question here that came up
>about the role of rspec as a language (format?) for representing
>information about resources and slivers in the GENI architecture. How
>do we balance the tension between standardization and extensibility?
It seems worth it to take a minute to frame the context here.
This data structure, whatever you call it, is the key boundary
interface between manufacturers of GENI components, who have to
create them, and the rest of the system, which has to use them. NSF
is eventually proposing to do competitive procurement of $300 million
or so of such components, from formal requests for proposals (which
means well formed specifications), from any number of different
vendors. NSF is also trying to be open to donations of useful
resources (eg, satellites, what have you) from other folks who might
be willing to make them available if they could figure out how.
It is, in my view, a very basic goal of the design that as many of
these components work with as much of the rest of the system as
possible. To make this happen, two things would seem to be true:
1) The design should encourage as much common understanding of what
an RSpec *means* as possible, across different communities,
components, component manufacturers, service creators, tool builders,
and researcher/users - so that we get as much interoperability as
possible, and so that it's as easy (and useful) as possible for a new
component vendor/creator/whatever to add themselves in.
2) The RSpec specification itself has to be as *clear* as possible,
so that random folks can figure out what the heck is going on.
To my mind this argues for as much standardization - or maybe I
should say "agreement" - as we can. If I thought there was any way to
do it, I'd argue that GENI would be best served by a standard
*non-extensible* RSpec, which would at least create some chance that
everything would work with everything else.
But of course that won't work.
So, as you say, we're looking for an extensibility model that
balances these things. I would say it as "an extensibility model that
encourages as much commonality as possible, but still allows for
evolution and change".
Now, in fact, Ted & Rob's talk yesterday outlined a "two-step"
extensibility model - although I agree it went by very quickly. The
main properties of this model are
a) An "object/subclass" flavor, so that, for example, if you have a
new sort of router with unique parameters, you can describe it as
such, and people who understand your parameters will get them, while
others will still understand it as a "router".
b) Within the XML container there are two (at least) levels of
extensibility - call them "private" and "standardized". You're free
to do anything you want with the private namespace - if it made sense
to you to put in a private attribute called "SensorML-Desc", noone
would stop you, although it might have to work as a request format as
well as a description format.
c) We imagine some process - to be clear, *not* the CFWG, since it
has to survive into the construction and operational phase of GENI as
well as the design phase - that would be responsible for elevating
new description attributes from the private to the standardized
namespace. You could also imagine intermediate "sub-community"
processes that would elevate attributes from the private namespace to
a level of shared agreement across some community of interest, such
as sensors. But other than its existence, nothing about this process
has even been proposed yet, let alone defined.
>http://www.science.uva.nl/research/sne/ndl). We should at least ask the
>question of whether we can get where we want to go in some other way,
>e.g., by extending NDL.
IMO this is sort of an orthogonal issue - if there's an existing (and
fairly community-neutral) format that we can build on to meet the
objectives above, we certainly aren't precluding it. We've already
swiped a lot of existing stuff for interface descriptions, etc. etc.
Cheers,
John
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: questions on RSpecs from GEC2 meeting
| Free embeddable forum powered by Nabble | Forum Help |
