OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] Namespace management (corrected spelling)


I think it should cover more than just "applying a value set". I'd liek to
see a best practice document that makes recommendations for designing and
using taxonomies, whether or not they provide a value set.

Anne

> -----Original Message-----
> From: Daniel Feygin [mailto:feygin@unitspace.com]
> Sent: Wednesday, March 12, 2003 10:24 AM
> To: 'Anne Thomas Manes'; 'Rogers, Tony'; 'Max Voskob'; 'uddi-spec'
> Subject: RE: [uddi-spec] Namespace management (corrected spelling)
>
>
> Anne,
>
> Can you be more specific?  Do you mean something like "Applying a
> value set
> in UDDI" (to complement the existing TN "Providing A Value Set For Use In
> UDDI Version 3" -
> http://oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-
> valuesetpr
> ovider-20030212.htm)?  I don't think that would alleviate the issue I am
> trying to raise, because I am pointing to potential misuse of the
> capabilities that would still remain in the spec.
>
> Daniel
>
>
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Wednesday, March 12, 2003 4:33 PM
> > To: Daniel Feygin; 'Rogers, Tony'; 'Max Voskob'; 'uddi-spec'
> > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> >
> >
> > I think we need a technical note (best practice) on how to
> > use keyedReferences.
> >
> > > -----Original Message-----
> > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > Sent: Wednesday, March 12, 2003 3:25 AM
> > > To: 'Rogers, Tony'; 'Anne Thomas Manes'; 'Max Voskob'; 'uddi-spec'
> > > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> > >
> > >
> > > Anne, Max, Tony,
> > >
> > > I am not too happy with a 'plethora of specialised bags'
> > myself, but I
> > > see it as a potential replacement (lesser?) evil to the
> > super-flexible
> > > tModel super-structure, which almost invites misuse and
> > overuse.  It
> > > can be shown that tModels (along with their contained
> > keyedReferences)
> > > alone permit the modeling of an arbitrary information set
> > all within a
> > > UDDI registry.  If everybody else is comfortable with that, then I
> > > rest my case.
> > >
> > > Daniel
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
> > > > Sent: Wednesday, March 12, 2003 2:23 AM
> > > > To: Daniel Feygin; Anne Thomas Manes; Max Voskob; uddi-spec
> > > > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> > > >
> > > >
> > > > This effect can be achieved, albeit a little less
> > conveniently, by
> > > > defining categorisation tModels for these categories (eg:
> > > > "processCategory"), then marking the tModels that would
> > be used in
> > > > the specialised bags with those categories. Taking your first
> > > > example, the tModel you are using for
> > > > "abc.org:processes:DirectMaterialsProcurement_v1.0"
> > > > would be marked as a "processCategory". Then the user can
> > find all
> > > > instances of "processCategoryBag" entries by locating all tModels
> > > > that have the "processCategory" in their category bag, and then
> > > > finding all the matching entries. If they are businesses,
> > a nested
> > > > findTModel in the findBusiness would do the job nicely.
> > > >
> > > > Sure, it isn't as simple, but it does avoid cluttering
> > what should
> > > > be a general purpose data design with a plethora of specialised
> > > > bags. I'm of the opinion that the UDDI data design is already
> > > > over-provided with specialised types - I'd far prefer to see a
> > > > reduction in the number of types than an increase.
> > > >
> > > > Hmm - sorry if that got into a bit of a rant - I've been fighting
> > > > with some obstreperous code, and sometimes it makes be grumpy :-)
> > > >
> > > > Tony Rogers
> > > >
> > > > -----Original Message-----
> > > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > > Sent: Wednesday, 12 March 2003 0:26
> > > > To: 'Anne Thomas Manes'; 'Max Voskob'; 'uddi-spec'
> > > > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> > > >
> > > >
> > > > Anne,
> > > >
> > > > I mean that there could be specialized derivations of
> > categoryBags,
> > > > keyedReferences and tModels instead of the generic ones.  Their
> > > > meaning would be more apparent to users and they would
> > more closely
> > > > follow the semantics of the concepts they are used to model.  For
> > > > example, there could be specialized categoryBags to
> > denote process
> > > > flows called processCategories, schemaCategories for schemas and
> > > > businessCategories for traditional taxonomies (examples below
> > > > are only to demonstrate the overall modeling principles of
> > > > the approach): <processCategories>
> > > >   <processReference
> > > >     processKey="abc.org:processes:DirectMaterialsProcurement_v1.0"
> > > >     roleValue="seller" />
> > > > </processCategories>
> > > > <schemaCategories>
> > > >   <schemaReference
> > > >     schemaKey="open-applications.org:schemas:OAGIS_v8.0" />
> > > > </schemaCategories> <businessCategories>
> > > >   <taxonomyReference
> > > >     taxonomyKey="uddi:uddi.org:categorization:unspsc"
> > > >     keyName="UNSPSC: Livestock"
> > > >     keyValue="101015" />
> > > > </businessCategories>
> > > >
> > > > When an inquiry on a given categorization is performed,
> > the inquirer
> > > > is certainly aware that what is being searched on is a
> > process flow,
> > > > business taxonomy or UDDI-specific concept (such as
> > owningBusiness
> > > > or isReplacedBy), so there would be no adverse impact for inquiry
> > > > use patterns.  The same applies to publication.
> > > >
> > > > This approach would imply that generally we might consider making
> > > > such specialized derivations for the types of tModels that
> > > > correspond to the values in the uddi-org:types category
> > system.  At
> > > > this time all of these concepts are represented as raw
> > tModels with
> > > > no semantic differentiation, although it is apparent that
> > they vary
> > > > greatly in their intended use.
> > > >
> > > > Daniel
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > > Sent: Sunday, March 09, 2003 11:38 PM
> > > > > To: Max Voskob; 'uddi-spec'
> > > > > Subject: RE: [uddi-spec] Namespace management
> > (corrected spelling)
> > > > >
> > > > >
> > > > > Daniel,
> > > > >
> > > > > Can you explain more what you mean by task-oriented structures?
> > > > >
> > > > > I don't really see a necessity to create a host of
> > > > different entities
> > > > > to represent different technical models, specifications,
> > > > frameworks,
> > > > > or process flows, but perhaps I don't quite understand
> > what you're
> > > > > trying to accomplish.
> > > > >
> > > > > tModels are typed. Therefore each tModel type can represent
> > > > different
> > > > > information. Because tModels have been designed to be generic,
> > > > > they can represent pretty much anything -- including tasks.
> > > > >
> > > > > keyedReferences let you associate tModels anyway you
> > want to. For
> > > > > example, in Max's e-government example, you could associate
> > > > a set of
> > > > > related tModels via a framework meta-namespace (or
> > whatever naming
> > > > > scheme you want to use).
> > > > >
> > > > > Anne
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > > > > Sent: Sunday, March 09, 2003 1:26 PM
> > > > > > To: 'uddi-spec'
> > > > > > Subject: Re: [uddi-spec] Namespace management (corrected
> > > > > > spelling)
> > > > > >
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > I agree with what you say, but there is a good
> > example of ebXML
> > > > > > Registry for us to avoid.
> > > > > >
> > > > > > They have their specialized entities, highly customized
> > > > > datamodel and
> > > > > > other complexities. It doesn't make their spec thinner
> > > > than the UDDI
> > > > > > spec nor less complex or ambiguous. UDDI is an
> > obvious winner in
> > > > > > this respect. UDDI can do more with less. Isn't it a
> > good thing?
> > > > > >
> > > > > > We may need to change such basic concepts as tModel and
> > > > > key-name-value
> > > > > > in the future, but there is a way around it for now. Users
> > > > > (customers)
> > > > > > do not want to wait another couple of years for v.4 :(
> > > > > >
> > > > > > Cheers,
> > > > > > Max
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Daniel Feygin" <feygin@unitspace.com>
> > > > > > To: "'Max Voskob'" <mvoskob@msi.net.nz>; "'uddi-spec'"
> > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > Sent: Monday, March 10, 2003 1:22 AM
> > > > > > Subject: RE: [uddi-spec] Namespace management (corrected
> > > > > > spelling)
> > > > > >
> > > > > >
> > > > > > > Max, TC,
> > > > > > >
> > > > > > > I would group all the information artifacts you refer to as
> > > > > > > metadata, which would help to differentiate it from
> > business
> > > > > > > content.  As I briefly mentioned in my previous
> > > > message, UDDI is
> > > > > > > capable of storing references to any metadata files using
> > > > > tModels,
> > > > > > > although it should be explored what needs to be done to
> > > > > make service
> > > > > > > metadata more workable and useful in UDDI.
> > > > > > >
> > > > > > > It is possible that this can be adequately addressed with
> > > > > additional
> > > > > > > guidance/use cases on the current capabilities of UDDI.
> > > > > > > Another possibility is to re-design everything related to
> > > > > tModels/metadata
> > > > > > > in V4 (or later), because tModels may be perceived
> > as somewhat
> > > > > > > functionally overloaded (and therefore overwhelming to
> > > > > the developer
> > > > > > > community) - they are used for several *distinct*
> > > > > purposes ranging
> > > > > > > from categorizations (real-world taxonomies) and Web
> > > > > service types
> > > > > > > (e.g.
> > > > > > > WSDL) to system-specific concepts (as in owningBusiness and
> > > > > > > isReplacedBy) and would-be metadata like schemas (e.g.,
> > > > > XSD), process
> > > > > > > definitions (e.g., BPEL4WS, WSCI) and other (possibly
> > > > > QoS, fail-over and
> > > > > > > load-balancing alternatives, etc.).
> > > > > > >
> > > > > > > It seems that tModels and keyedReferences were intended
> > > > > to be very
> > > > > > > flexible so as to satisfy a broad range of
> > unidentified future
> > > > > > > requirements through modeling and gluing together
> > of different
> > > > > > > features entirely as tModels and keyedReferences.
> > Indeed they
> > > > > > > enable a great variety of unforeseen circumstances and
> > > > > requirements
> > > > > > > to be addressed. Now that many of these requirements have
> > > > > > > become known, perhaps it is time for them to be modeled
> > > > > differently using
> > > > > > > more solid task-oriented structures.
> > > > > > >
> > > > > > > Daniel
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > > > > > > Sent: Thursday, March 06, 2003 12:10 AM
> > > > > > > > To: uddi-spec
> > > > > > > > Subject: Re: [uddi-spec] Namespace management
> > > > > (corrected spelling)
> > > > > > > >
> > > > > > > >
> > > > > > > > Daniel,
> > > > > > > >
> > > > > > > > The information artifacts can be almost anything,
> > e.g., XML
> > > > > > > > schemas, documentation, sample XML documents, WSDL files,
> > > > > > > > namespace identifiers, documents for ebXML (CPP, CPA,
> > > > etc), XML
> > > > > > > > Topic Maps files, taxonomies, etc, etc, etc.
> > > > > > > >
> > > > > > > > Web services do not exist on its own. If the
> > webservice is
> > > > > > > > as simple as RPC then it's easy, but what if it's
> > a complex
> > > > > > > > one? Let's say "CreateCustomer" web-service when a complex
> > > > > XML document
> > > > > > > > is passed onto the web-service and an even more
> > complex XML
> > > > > > > > document is returned back. Those documents may contain
> > > > > a dosen of
> > > > > > > > infosets from different namespaces and so on. Another
> > > > > example is a
> > > > > > > > popular 360 degree view of customer information
> > (basically
> > > > > > > > any
> > > > > > > > information) where all entities are described using
> > > > XML Schemas
> > > > > > > > and linked together to form one enterprise- /
> > government- /
> > > > > > > > industry- / national - wide framework. (see the
> > > > > attached picture)
> > > > > > > >
> > > > > > > > Take for example an e-Government. They adopt or
> > > > produce schemas
> > > > > > > > for election, name, address, etc. These schemas,
> > > > again, form a
> > > > > > > > framework.
> > > > > > > >
> > > > > > > > The framework components are registered in the registry
> > > > > and stored
> > > > > > > > elsewhere. If I have a NS identifier I go to the
> > > > > registry and find
> > > > > > > > everything that relates to that NS ID, including
> > the schema,
> > > > > > > > documentation for the schema, sample XML files, who
> > > > > wrote it, who
> > > > > > > > use it, what status of each document is and all sort of
> > > > > > > > other crucial information.
> > > > > > > >
> > > > > > > > All those information artifacts still relate to
> > > > > web-services. For
> > > > > > > > example, a WS A recieves an XML document with 3 different
> > > > > > > > namespaces. The web service can deal with 2 only and
> > > > > then has to
> > > > > > > > pass the document to another web service for
> > > > > processing. The WS A
> > > > > > > > looks up the registry to find the webservice by at say
> > > > > NS ID and
> > > > > > > > get all the binding it needs to call it. I think
> > > > there can be a
> > > > > > > > hundred of other runtime interaction example.
> > > > > > > >
> > > > > > > > Web-services do not come on their own. They depend on
> > > > > many other
> > > > > > > > information artifacts that may be required for their
> > > > > processing at
> > > > > > > > runtime or development (design time). Speaking of the
> > > > > > > > multiple purposes I mean that for private registries the
> > > > > > > > content
> > > > > cannot be
> > > > > > > > limited to just "business" and "service". It is much
> > > > > broader than
> > > > > > > > that.
> > > > > > > >
> > > > > > > > Customers want to have one registry for all artifacts
> > > > > and do not
> > > > > > > > spread the $$$, time and effort across UDDI for WS,
> > > > > ebXML registry
> > > > > > > > for schemas and other stuff, Tibco for something else
> > > > > and so on.
> > > > > > > > Customers want one registry to rule them all.
> > > > > > > >
> > > > > > > > Sorry, I'm not sure I expressed myself clearly.
> > Please, let
> > > > > > > > me know if it's still confusing.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Max
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Daniel Feygin" <feygin@unitspace.com>
> > > > > > > > To: "'Max Voskob'" <mvoskob@msi.net.nz>; "'uddi-spec'"
> > > > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > > > Sent: Wednesday, March 05, 2003 1:36 AM
> > > > > > > > Subject: RE: [uddi-spec] Namespace management
> > > > > (corrected spelling)
> > > > > > > >
> > > > > > > >
> > > > > > > > > Max,
> > > > > > > > >
> > > > > > > > > It could certainly make for an interesting discussion,
> > > > > > > > > particularly since it is substantiated by
> > specific client
> > > > > > > > > references.
> > > > > > > > We do have
> > > > > > > > > UDDI managing WSDL registrations and there is really
> > > > > > > > > nothing technically preventing anyone from, say,
> > > > registering process
> > > > > > > > > specifications or schema references in UDDI
> > using tModels
> > > > > > > > (other than
> > > > > > > > > that there are no use cases or guidance for
> > doing so in a
> > > > > > > > uniform and
> > > > > > > > > recognizable way).
> > > > > > > > >
> > > > > > > > > In terms of business content, I - and UnitSpace
> > - see UDDI
> > > > > > > > > already being a registry of content *services*; these
> > > > > services
> > > > > > > > > are where business information entities can be
> > discovered,
> > > > > > > > > retrieved and managed.  But there is a
> > difference between
> > > > > > > > > maintaining service metadata and business content.
> > > > Extending
> > > > > > > > > UDDI to perform business content management
> > would require
> > > > > > > > > substantial, though probably backwards-compatible,
> > > > changes to
> > > > > > > > > the information model and
> > > > > > > > the API's.
> > > > > > > > > My fear is that most business content has a
> > > > different profile
> > > > > > > > > that metadata with regard to security, applicable
> > > > operations,
> > > > > > > > > functional role and target users, although that's
> > > > > debatable and
> > > > > > > > > perhaps a plausible alignment other than proposed
> > > > > above ("UDDI
> > > > > > > > > is a
> > > > > > > > registry of
> > > > > > > > > content services, which in turn manage content") is
> > > > possible.
> > > > > > > > >
> > > > > > > > > I guess it would be helpful to understand more
> > > > > specifically what
> > > > > > > > > is being proposed for discussion.  My questions to Max
> > > > > > > > therefore are: 1.
> > > > > > > > > What sort of information artifacts are you
> > referring to?
> > > > > > > > > 2. Specifically, what are the attempted
> > multiple purposes
> > > > > > > > > of
> > > > > > > > using UDDI
> > > > > > > > > that you came across?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Daniel
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > > > > > > > > Sent: Monday, March 03, 2003 9:52 PM
> > > > > > > > > > To: uddi-spec
> > > > > > > > > > Subject: Re: [uddi-spec] Namespace management
> > (corrected
> > > > > > > > > > spelling)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Matthew,
> > > > > > > > > >
> > > > > > > > > > That's the problem. UDDI is being considered
> > by many as
> > > > > > > > > > a
> > > > > > > > registry
> > > > > > > > > > of informational artifacts for an enterprise. I'm
> > > > > one of them.
> > > > > > > > > > :) And UDDI is almost there! It's got a huge
> > > > > potential, much
> > > > > > > > > > more potential then any competing standard at the
> > > > > moment. All
> > > > > > > > we need is
> > > > > > > > > > a little effort to get the external
> > taxonomies going and
> > > > > > > > > > probably add a couple more minor features without
> > > > > changing the
> > > > > > > > > > concept. On the other hand I can't see the
> > > > > consensus amongst
> > > > > > > > > > the members to rephrase the purpose of UDDI.
> > > > > > > > > >
> > > > > > > > > > I personally came across quite a few cases where
> > > > > organisations
> > > > > > > > > > (incl. NZ Gov, OZ Gov) were seriously considering
> > > > UDDI as a
> > > > > > > > > > multi-purpose registry. They did so not from
> > > > > misunderstanding
> > > > > > > > > > of UDDI, but from seeing a great potential in the
> > > > > standard and
> > > > > > > > > > its implementations.
> > > > > > > > > >
> > > > > > > > > > I would suggest to include it in the agenda of one of
> > > > > > > > > > the
> > > > > > > > upcoming
> > > > > > > > > > telecons and discuss it openly, if the other TC
> > > > members are
> > > > > > > > > > interested, of coz.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Max
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Matthew Dovey" <matthew.dovey@las.ox.ac.uk>
> > > > > > > > > > To: "Max Voskob" <mvoskob@msi.net.nz>; "uddi-spec"
> > > > > > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > > > > > Sent: Tuesday, March 04, 2003 4:16 AM
> > > > > > > > > > Subject: RE: [uddi-spec] Namespace management
> > (corrected
> > > > > > > > > > spelling)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This sounds like the problem space that metadata
> > > > > > > > registries and ISO
> > > > > > > > > > 11179 aim to address (see
> > > > > http://www.schemas-forum.org/ for a
> > > > > > > > > > EU project in this area).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I'm pretty sure that this isn't a question
> > that UDDI has
> > > > > > > > attempted
> > > > > > > > > > to tackle. I'm not entirely sure whether it is a
> > > > > > > > > > question
> > > > > > > > that UDDI
> > > > > > > > > > should tackle - my undertanding is that UDDI is a
> > > > > directory of
> > > > > > > > > > WebServices rather than a universal directory for
> > > > > everything
> > > > > > > > > > Web/WebService related (but that's just my opinion)
> > > > > > > > > >
> > > > > > > > > > Matthew
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > <snip>
> > > > > > > > > >
> > > > > > > > > > Imagine an organisation where 25 departments are
> > > > > > > > > > creating
> > > > > > > > different
> > > > > > > > > > XML documents and formalise them with all sorts of
> > > > > > > > > > documentation including XML Schemas. How do they
> > > > > ensure that
> > > > > > > > > > the new
> > > > > > > > namespace ID
> > > > > > > > > > they've just come up with is not already used
> > somewhere
> > > > > > > > else within
> > > > > > > > > > the organisation? Sure, they can write a 25 page guide
> > > > > > > > how to name
> > > > > > > > > > their namespaces (if they can't they email me and I'll
> > > > > > > > write one for
> > > > > > > > > > them :), but it's hard to reinforce anyway.
> > > > > > > > > >
> > > > > > > > > > <snip>
> > > > > > > > > > Can one do it using available UDDI means at
> > the moment?
> > > > > > > > > > I don't think so, but I can be wrong. Please
> > correct me.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > ----------------------------------------------------------------
> > > > > > > > > To subscribe or unsubscribe from this elist use the
> > > > > subscription
> > > > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > ------------------------------------------------------------
> > > > > > > > --
> > > > > > > > --------------
> > > > > > > > ----
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > --------------------------------------------------------------
> > > > > > > --
> > > > > > > To subscribe or unsubscribe from this elist use the
> > subscription
> > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ----------------------------------------------------------------
> > > > > > To subscribe or unsubscribe from this elist use the
> > subscription
> > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > To subscribe or unsubscribe from this elist use the subscription
> > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > To subscribe or unsubscribe from this elist use the subscription
> > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > >
> > > >
> > >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]