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)


Daniel,

Are you proposing some type of semantic modification to how you process
these specialized categoryBags? Your examples show only the standard key,
name, and value attributes, so I don't really see how the specialization of
the categoryBags really helps the situation (except in terms of
readability). And I fear that having a plethora of specialized categoryBags
might cause confusion -- i.e., I might have a situation where a taxonomy
could reasonably fit into more than one type of categoryBag. Which one
should I put it in? When I search, which Bag should I search in?

As an alternative, perhaps we might consider adding a type attribute to the
keyedReference structure which would permit you to identify the type of
taxonomy being referenced. But I'm still hesitant to do so because of the
potential confusion it might cause. I'm not convinced that it really adds a
lot of value. I actually think the simplest way to solve the readability
issue is to specify more information in the keyName field.

Keep in mind that you wouldn't have a different taxonomy type for each
tModel type. You can only use tModels of type "categorization" or
"identifier" within a keyedReference. If you want to reference a schema,
namespace, wsdl file, etc, you reference it using a taxonomy, e.g.:

   <keyedReference
     tModelKey="uddi:uddi.org:categorization:schema"
     keyName="schema"
     keyValue="http://www.example.org/xyzschema" />

   <keyedReference
     tModelKey="uddi:uddi.org:xml:namespace"
     keyName="namespace"
     keyValue="urn:foo" />

   <keyedReference
     tModelKey="uddi:uddi.org:categorization:wsdl"
     keyName="wsdl file"
     keyValue="http://www.example.org/xyzwsdl" />

I think this approach is much simpler and more versatile than creating
specialized Bag structures.

(I do think it would be appropriate for us to define these taxonomy tModels,
though -- thus far, only namespace has been proposed as part of the WSDL
TN.)

Regards,
Anne

> -----Original Message-----
> From: Daniel Feygin [mailto:feygin@unitspace.com]
> Sent: Tuesday, March 11, 2003 8:26 AM
> 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>




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