← Prev in month ← Prev in thread
Next in thread → Next in month →

Re: [uddi-spec] TN/BP or Profile

From
Anne Thomas Manes <>
Date
2005-10-11T12:51:07+00:00
ID
Thread
Re: [uddi-spec] TN/BP or Profile
Think this is actually the more important distinction -- the ebXML
RegRep team represents the profiles as normative specifications, and I
assume they will promote them to be part of the official OASIS
standard. UDDI TNs are not normative, therefore they are perceived as
less valid.

Anne

On 9/26/05, Luc Clement <> wrote:

I for one do have an issue with this. We have a long 
history of the term along with an agreed to process - see [1] - this in fact 
predates OASIS. I see no reason to change this at this time as this would only 
cause confusion within the user community.

 

Furthermore, I don't see how we could/would ever consider 
something (effectively normative) as the WSDL-UDDI v2 mapping a "profile"; same 
goes for any of the TNs we've issued. Our TNs are very specific. They don't 
offer many degrees of freedom or pick from alternatives (as would a profile) - 
they are simply "a non-normative document accompanying the UDDI Specification that 
provides guidance on how to use UDDI registries. While Technical Notes represent 
the TC's view on some UDDI-related topic, they may be prospective in nature and 
need not document existing practice."

 

We should in fact consider elevating the status of some of 
our TNs to OASIS specs. 

 

I'm afraid I don't see Paul's issue here but am more than 
happy to discuss during the call tomorrow.

 

Luc

 

 

[1] 
http://www.oasis-open.org/committees/uddi-spec/doc/process/uddi-spec-tc-process-20021212.htm#_Toc27444265

From: Rogers, Tony [mailto:] 

Sent: Monday, September 26, 2005 19:06
To: Paul Denning; 

Subject: RE: [uddi-spec] TN/BP or 
Profile

I have no problem with adopting the "profile" terminology, and I like the 
suggestions you've made, but I wonder if this will introduce conflict with those 
familiar with the WS-I Basic Profile? Anyone have an idea about this?

 

Tony Rogers

  
-----Original Message----- 
From: Paul Denning 
  [mailto:] 
Sent: Sat 24-Sep-05 3:38 
To: 
   
Cc: 
Subject: [uddi-spec] 
  TN/BP or Profile

  
UDDI has used the terms "Technical Note (TN)" and "Best 
  Practice
(BP)" to talk about ways of using UDDI in a consistent 
  manner.

The OASIS ebXML Registry TC has a similar concept, but they 
  call them
"Profiles".

This difference in terminology for the same 
  basic concept can be confusing.

I get the feeling that some people 
  consider an ebReg "profile"
somehow more legitimate or formal than a UDDI 
  TN/BP.

I think they are equal.

Using different terminology seems 
  to be used as a way to
differentiate ebREg from UDDI and make ebReg look 
  more suitable for
enterprise deployments.  There are other differences 
  besides Profile
vs TN/BP, but when ebReg says that they have profiles for 
  this or
that, it somehow sounds like UDDI does not have something 
  equivalent
or as formal.   Some people looking to compare and 
  contrast UDDI and
ebReg may ask "does UDDI have an XYZ profile like 
  ebReg?"  The answer
may be "yes, but we call it an XYZ 
  TN".

Where am I going with this?

I propose that the UDDI Spec TC 
  adopt the term "profile" as a
replacement for TN and BP.

The boiler 
  plate for a UDDI Profile could say something like "UDDI
profiles provide 
  technical notes and best practice for using UDDI."

Another motivation 
  for this proposal is that the term "profile" is
used quite a bit by the US 
  DoD, who is my customer/sponsor.  People
tune-in when the word 
  "profile" is used more so than TN/BP.

Historically, a standards profile 
  has referred to additional
constraints associated with implementation of a 
  standard.  Standards
that have been developed by committees sometimes 
  include options that
are included as a way of reaching consensus within the 
  committee.  A
profile of such as standard may be developed by a 
  vertical industry
or some other organization.  For example, WS-I has a 
  Basic Profile
that specifies constraints on the use of SOAP, WSDL, and UDDI 
  with
the goal of better interoperability.  Profiles may provide a way 
  of
defining a standard "subset" of a broader standard.

ebReg and the 
  proposed UDDI profiles would be a little different in
that these specs 
  provide some basic building blocks.  The idea of a
profile in this 
  context is not to identify fewer building blocks
(standard subsets), but it 
  is to document one arrangement of the
building blocks to solve a particular 
  problem in a consistent
way.  If people publish to a registry in a 
  consistent manner, then
queries to search for those things can be 
  simpler.  Nonetheless, the
term "profile" is being used in a more or 
  less consistent way when
compared to the historical use of the standards 
  "profile".

Some other advantages of both ebReg and UDDI using the term 
  "profile"
include serendipitous discovery.  People searching Google 
  (for
example) for "profile" (and some other terms) may get a few hits 
  for
UDDI documents mixed in with ebXML profiles if "profile" is 
  adopted
as a replacement for TN/BP.  That person may have known about 
  ebReg,
but may have not known about UDDI.  Without UDDI using the 
  term
"profile", these UDDI hits may not have shown up in the 
  search
results, and that person would not have known about UDDI.  
  Likewise,
someone who knows about UDDI. but not ebXML may search for 
  "profile"
and may learn about ebXML.

I don't think ebReg TC is going 
  to change to using TN/BP terminology.

OASIS may want to consider 
  adopting a general policy to use the term
"profile" when talking about 
  subsets or ways of using (and extending)
OASIS 
  standards.

Comments?

Paul

---------------------------------------------------------------------
To 
  unsubscribe from this mail list, you must leave the OASIS TC that
generates 
  this mail.  You may a link to this group and all your TCs in 
  OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
← Prev in month ← Prev in thread
Next in thread → Next in month →