[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]