Subject: Re: Registry concern with specifying common vertical structures
Hullo Scott, Farrukh, all. I've been lurking here for a while getting up to speed with ebXML but in general the problem with ab initio support for vertical domains, is that the need for customization usually introduces proprietary extensions, reducing interoperability. (remember EDI anyone :) As ebXMLs goals primary concern is interoperability perhaps the less vertical structuring the better. On the other hand, a common substrate or set of building blocks should be provided to promote interoperability of v2v x2x interactions. The OMG have a nice solution as standards bodies go by separating architecture and horizontal necessities of distributed comms from vertical modus operandi, whilst at the same time encouraging vertical domains to standardize within their arenas leveraging (and improving) the common core. I hope im not stating the obvious, but these days I write the obvious down and stick them to my monitor, otherwise I forget the obvious increase my bad kharma score with time space continuum. A concrete example from UDDI v1. Support for NAICS Rev 1997 and UNSPSC v3.1 'in the tin' is great, but (even from my CGI days) the one thing I still hate about entering my postal address into some web based systems, is that they enforce a ZIP code, although the Irish postal system hasn't found a need for them yet. Even today I spend ages in these forms trying to figure out a valid ZIP code so I can complete my purchase order! Its the age old 'extensibility versus customizability' opportunity all over again. Qualified with a need for interoperability, less is more and so I say yes to phone numbers as long as a phone number has '1 or many address lines'. If ZIP codes, or sort codes are required for a given domain, they can be decorated in for that (those) domains. Still, i'd love to see a lowest common denominator that suits everyone which promotes interoperability, but explicit support for decorability (and perhaps aliasing such decorations as unique types within an appropriate namespace - taxonomy) which provides the wished for customizability and extensibility. That would be the icing on the cake! Hopefully in a few weeks I can be a bit more ebXML lucid and specific, so please forgive my genericity. Nice to be working with you all though, and as this is my first time to type to you on this list, I hope i'm not putting foot in mouth, excuse the pun! Is mise le fior mheaser, Darach. At 10:36 AM 3/15/01 -0600, Scott Hinkelman wrote: >Farrukh, >You are fundamentally missing my point. > >>I am open to suggestions for improvement or replacement. However, in the >absence of anything better we have no viable alternative. > >"improvement' in my mind is to remove the current structure, not suggest a >replcement, and facilitate >the user community to define it. > >Scott Hinkelman, Senior Software Engineer >XML Industry Enablement >IBM e-business Standards Strategy >512-823-8097 (TL 793-8097) (Cell: 512-940-0519) >srh@us.ibm.com, Fax: 512-838-1074 > > > >Farrukh Najmi <najmi@east.sun.com> on 03/15/2001 10:25:22 AM > >To: Scott Hinkelman/Austin/IBM@IBMUS >cc: Farrukh Najmi <Farrukh.Najmi@Sun.COM>, David RR Webber > <Gnosis_@compuserve.com>, ebxml repository > <ebxml-regrep@lists.ebxml.org>, Ram Kumar <rkumar@msi.com.au>, Mary > Kay Blantz <mblantz@netfish.com>, ebxml-core@lists.ebxml.org >Subject: Re: Registry concern with specifying common vertical structures > > > >Scott, > >I agree that it shoul be someone else defining these things. The assumption >we >had was that CC would define it and we would use it. Since it did not >happen >that way we did what we had to. > >BTW IMHO, ebXML as a whole shoudl have a unified information model without >seams along team boundaries. Since we are rapidly running out of runway >nothing >big or global is likely to happen. Each group is under the gun to deliver >and >collaboration between teams is getting harder. > >I am open to suggestions for improvement or replacement. However, in the >absence of anything better we have no viable alternative. > >Scott Hinkelman wrote: > >> Farrukh, >> And as I mentioned in the meeting, I agree it is needed of course, but I >> believe it to be best to allow the utilzation community of an ebXML >> Registry define that structure. ebXML Registry is not UDDI, and most >likely >> there will be many ebXML Registries for specific communities, unlike >UDDI, >> and those communities are best served by letting *them* define that >> structure. >> >> Scott Hinkelman, Senior Software Engineer >> XML Industry Enablement >> IBM e-business Standards Strategy >> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) >> srh@us.ibm.com, Fax: 512-838-1074 >> >> Farrukh Najmi <najmi@east.sun.com> on 03/15/2001 09:52:06 AM >> >> To: Scott Hinkelman/Austin/IBM@IBMUS >> cc: David RR Webber <Gnosis_@compuserve.com>, ebxml repository >> <ebxml-regrep@lists.ebxml.org>, Ram Kumar <rkumar@msi.com.au>, Mary >> Kay Blantz <mblantz@netfish.com>, ebxml-core@lists.ebxml.org >> Subject: Re: Registry concern with specifying common vertical structures >> >> Scott, >> >> As I mentioned in the meeting yesterday it is common for registry specs >to >> define PostalAddress (UDDI defines Address as a type, OASIS defines the >> attributes of address but not the type, ISO 11179n defines type). I think >> we >> need the type in the model. The attributes could be tweaked. >> >> Just my 2cents. >> >> Scott Hinkelman wrote: >> >> > ISO?, CIQ?, HR-XML?, *? >> > I still question if PostalAddress should be in scope for formal >> > specification of the ebXML Registry at all. >> > >> > Scott Hinkelman, Senior Software Engineer >> > XML Industry Enablement >> > IBM e-business Standards Strategy >> > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) >> > srh@us.ibm.com, Fax: 512-838-1074 >> > >> > David RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 03/14/2001 >> > 09:28:56 PM >> > >> > To: ebxml repository <ebxml-regrep@lists.ebxml.org>, Ram Kumar >> > <rkumar@msi.com.au>, Mary Kay Blantz <mblantz@netfish.com> >> > cc: >> > Subject: RE: Registry concern with specifying common vertical >structures >> > >> > Reply from Ram - looks more promising than >> > first thought. >> > >> > This - and W.Kammerer on ISO seem possibles. >> > >> > Mary-Kay - comments? >> > >> > DW. >> > >> > -------------Forwarded Message----------------- >> > >> > From: "Ram Kumar", INTERNET:rkumar@msi.com.au >> > To: , INTERNET:ciq@lists.oasis-open.org >> > , INTERNET:ebxml-regrep@lists.ebxml.org >> > "'Karl Best'", INTERNET:karl.best@oasis-open.org >> > "'David RR Webber'", Gnosis_ >> > >> > Date: 3/14/2001 9:29 PM >> > >> > RE: RE: Registry concern with specifying common vertical structures >> > >> > David >> > >> > You are right that the work we are doing on name and address >> > standards is fairly heavy stuff. But the beauty is that it covers >> > any application that want to use simple representation of the name >> > and address to very detailed representation of name and address >> > elements. For example, if you have a postal address say, >> > >> > 23 Archer Avenue East >> > Boulder, Colorado 12345-8976 >> > >> > Following are some of the ways that you can represent the above address >> > using the XML standard we are working on: >> > >> > <address>23 Archer Avenue East >> > Boulder, Colorado 12345-8976 >> > </address> >> > >> > OR >> > >> > <address> >> > <addressline1>23 Archer Avenue East</addressline1> >> > <addressline2>Boulder, Colorado 12345-8976</addressline2> >> > </address> >> > >> > OR >> > >> > <address> >> > <streetnumber>23</streetnumber> <streetname>Archer</streetname> >> > <streettype>Avenue</streettype> >> > <streetpostdirection>East</streetpostdirection> >> > <cityname>Boulder</cityname> <statename>Colorado</statetame> >> > <postcode>12345</postcode> <extendedpostcode>8976</extendedpostcode> >> > </address> >> > >> > OR >> > >> > <address> >> > <street>23 Archer Avenue East</street> >> > <city>Boulder</city><state>Colorado<./state> >> > <postcode>12345-8976</postcode> >> > </address> >> > >> > This is the level of flexibility that we provide in our standard. >> Moreover, >> > please note >> > that our standard work can handle atleast more than 40-50 country >address >> > structures. >> > The point I am trying to make is that it is not compulsary to define >all >> > the >> > postal elements >> > to represent an address as you state. Most of the elements are >optional. >> > >> > Regards >> > >> > Ram >> > Chair, CIQ TC >> > OASIS >> > >> > > > > -----Original Message----- >> > > > > From: David RR Webber [mailto:Gnosis_@compuserve.com] >> > > > > Sent: Thursday, March 15, 2001 8:29 AM >> > > > > To: Karl Best >> > > > > Cc: ebxml-regrep@lists.ebxml.org; ciq@lists.oasis-open.org >> > > > > Subject: RE: Registry concern with specifying common vertical >> > > > > structures >> > > > > >> > > > > >> > > > > Message text written by Karl Best >> > > > > > >> > > > > RegRep'ers: >> > > > > >> > > > > There is an OASIS technical committee (Customer Information >> > > > > Quality, CIQ) >> > > > > working on this stuff; their work is fairly far along. Is >> > > > > there a way to >> > > > > coordinate efforts? >> > > > > >> > > > > </karl>< >> > > > > >> > > > > >>>>>>>>>>>>>>>>> >> > > > > >> > > > > Karl, >> > > > > >> > > > > I'm not sure that's the right answer - but it is an answer. >> > > > > >> > > > > Being on that TC and looking at the solution they are >> > > > > moving too - its awfully top heavy just for a registry >> > > > > entry owner details entry!!! >> > > > > >> > > > > Bit likely signing up for a new telephone line and having >> > > > > to state your mothers brothers uncles dad's date of birth. >> > > > > >> > > > > A sub-set of their approach may work , where the DTD >> > > > > has been skilfully restructured to make a simple highly >> > > > > level 90:10 possible - with options for greater >> > > > > granularity for the extended cases. >> > > > > >> > > > > This is another one of those - with 36hrs in a day we >> > > > > can get to it things.... >> > > > > >> > > > > DW. >> > > > > >> > > > > >> > > > > >------------------------------------------------------------------ >> > > > > To unsubscribe from this elist send a message with the single >word >> > > > > "unsubscribe" in the body to: ciq-request@lists.oasis-open.org >> > > > > >> > > > >> > > >> > >> > ----------------------- Internet Header >-------------------------------- >> > Sender: rkumar@msi.com.au >> > Received: from mailin5.bigpond.com ([139.134.6.78]) >> > by spdmgaac.compuserve.com (8.9.3/8.9.3/SUN-1.9) with ESMTP id >> > VAA19921 >> > for <Gnosis_@compuserve.com>; Wed, 14 Mar 2001 21:28:32 -0500 >(EST) >> > Received: from ram-kumar-pc ([139.134.4.54]) by >> > mailin5.bigpond.com (Netscape Messaging Server 4.15) with >SMTP >> > id GA7WEQ00.26A; Thu, 15 Mar 2001 12:32:50 +1000 >> > Received: from DC-29-207.bpb.bigpond.com ([203.40.29.207]) by >> > mail6.bigpond.com (Claudes-Lavish-MailRouter V2.9c 11/5205653); 15 Mar >> 2001 >> > 12:27:54 >> > From: "Ram Kumar" <rkumar@msi.com.au> >> > To: "'David RR Webber'" <Gnosis_@compuserve.com>, >> > "'Karl Best'" <karl.best@oasis-open.org>, >> > <ebxml-regrep@lists.ebxml.org>, <ciq@lists.oasis-open.org> >> > Subject: RE: Registry concern with specifying common vertical >structures >> > Date: Thu, 15 Mar 2001 12:11:54 +1100 >> > Message-ID: <006101c0acf8$b5e49fe0$b81a28cb@ram-kumar-pc.intranet> >> > MIME-Version: 1.0 >> > Content-Type: text/plain; >> > charset="iso-8859-1" >> > Content-Transfer-Encoding: 7bit >> > X-Priority: 3 (Normal) >> > X-MSMail-Priority: Normal >> > X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 >> > Importance: Normal >> > In-Reply-To: >> > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >> > >> > ------------------------------------------------------------------ >> > To unsubscribe from this elist send a message with the single word >> > "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org >> > >> > ------------------------------------------------------------------ >> > To unsubscribe from this elist send a message with the single word >> > "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org >> >> -- >> Regards, >> Farrukh > >-- >Regards, >Farrukh > > > > > > >------------------------------------------------------------------ >To unsubscribe from this elist send a message with the single word >"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org > >
Powered by
eList eXpress LLC