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] | [Elist Home]


Subject: RE: [uddi-spec] Basic Profile Version 1.0 - Working Group Draft


By pointing to the WS-I Basic Profile, my intent was not to restart discussions we already had but to give you an idea on what the Basic Profile is all about.
After sending the results from our last conference call to the WS-I Basic Profile WG (a copy is available at http://lists.oasis-open.org/archives/uddi-spec/200210/msg00022.html), which by the way summarize the reasons why we decided to not consider to adopt UTF-16 for UDDI Version 2, the Basic Profile WG slightly changed their position.

The compelling reason why ARBITRARY Web services must support both UTF-8 and UTF-16 (as specified in the Basic Profile) is that a potential user cannot programmatically derive the supported character encoding if only one of both is supported except by trial and error.
As far as UDDI (and other WELL-KNOWN meta Web services) is concerned, potential clients KNOW when they interact with a UDDI registry and since the UDDI specification mandates UTF-8, they KNOW that they must use UTF-8 (or use one of the tools available today that implicitely use UTF-8).
Thus, the WS-I Basic Profile WG is currently in a better position to accept UDDI's exception of the general rule.

Claus

-----Original Message-----
From: Daniel Feygin [mailto:feygin@unitspace.com]
Sent: Dienstag, 22. Oktober 2002 10:59
To: uddi-spec@lists.oasis-open.org
Cc: 'Keisuke Kibakura'
Subject: RE: [uddi-spec] Basic Profile Version 1.0 - Working Group Draft


Keisuke,

Sorry, I did not mean to imply that UDDI registry is merely an XML
processor.  In fact, we are in complete agreement on both of your
statements.

However, we must decide whether UDDI client must be able to use any
valid XML conforming to UDDI schema or whether it is a appropriate use
of XML to artificially restrict usable information set to XML instances
encoded in UTF-8.  The reason I now believe the restriction is
artificial is because I see no significant implementation issues
(although I've done no detailed analysis and there may indeed be some
impact with regard to things like storage, search and sorting), since
XML processors must already be capable of parsing UTF-16 XML documents
and this applies to both server and client.

It appears that there is no rationale behind UDDI specifications'
restriction on messages being expressed in UTF-8, and therefore
implementation impact on adopting UTF-16 support should be minimal,
because XML processing is delegated to lower level infrastructure.
Another factor in favor of resolving this issue by adopting UTF-16
support is that UDDI clients may not be able to control precisely how
their requests are serialized into XML.

Daniel


> -----Original Message-----
> From: Keisuke Kibakura [mailto:kibakura@jp.fujitsu.com] 
> Sent: Tuesday, October 22, 2002 11:56 AM
> To: uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Basic Profile Version 1.0 - Working 
> Group Draft
> 
> 
> Dan, 
> 
> UDDI implementation uses an XML processor, which must conform to 
> the XML specification, but UDDI itself is not an XML processor.
> 
> I don't think the current UDDI specification is illegal, 
> though it uses only UTF-8. 
> 
> --
> Keisuke Kibakura
> 
> 
> >>>>> On Tue, 22 Oct 2002 10:44:32 +0400,
> >>>>> Daniel Feygin <feygin@unitspace.com> wrote :
> 
> > Working group draft states: 
> >     All XML Processors must support UTF-8 and UTF-16, per 
> the XML 1.0 
> > specification.
> > 
> > According to this statement, UTF-16 support is mandated by 
> XML 1.0.  
> > If that is correct, then we cannot claim that UDDI Web Service is a 
> > true XML Web Service - it is a service supporting only a 
> subset of XML 
> > expressed in UTF-8.
> > 
> > This certainly implies that some errata is required to correct the 
> > problem - the question is whether we amend the specifications to 
> > clearly indicate that UDDI is not in compliance with XML 1.0 (and 
> > therefore with WS-I Basic Profile) or whether we become 
> XML-compliant 
> > with respect to the UTF-16 issue.
> > 
> > Daniel Feygin
> > UnitSpace
> > 
> > 
> > > -----Original Message-----
> > > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > > Sent: Monday, October 21, 2002 7:11 PM
> > > To: 'uddi-spec@lists.oasis-open.org'
> > > Subject: [uddi-spec] Basic Profile Version 1.0 - Working 
> Group Draft
> > > 
> > > 
> > > Here is the link to the WS-I Basic Profile that was recently
> > > made public: 
> > > 
> http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WG
D.htm.
> > As for the character encoding issue we already discusses, the 
> > requirement to support both UTF-8 and UTF-16 is listed as 
> > "R1012" in section 4.1. Section 3.2 defines conformance 
> > (against the profile) of Web services in general.
> > 
> > Claus

----------------------------------------------------------------
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] | [Elist Home]


Powered by eList eXpress LLC