[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Is there a way to reuse and extend an enumeration in XML s
The notion of your trick behind the stylesheets is much the same as that of CAM (the Content Assembly Mechanism), tirelessly pushed by David RR Webber, whom we've affectionately nicknamed "the David Lyon of ebXML." See http://lists.oasis-open.org/archives/ubl-dev/200503/msg00015.html. I believe the intent is to give folks a means of extending code lists using the native W3C XSD schema facility. That may or may not have been specified by Jon Bosak or the UBL Code List group as a hard requirement. William J. Kammerer Novannet Columbus, OH 43221-3859 . USA +1 (614) 487-0320 ----- Original Message ----- From: "Chiusano Joseph" <chiusano_joseph@b...> To: "William J. Kammerer" <wkammerer@n...>; "XML Developers List" <xml-dev@l...> Sent: Sunday, 06 March, 2005 01:46 PM Subject: RE: Is there a way to reuse and extend an enumeration in XML schema > -----Original Message----- > From: William J. Kammerer [mailto:wkammerer@n...] > Sent: Sunday, March 06, 2005 1:38 PM > To: XML Developers List > Subject: Re: Is there a way to reuse and extend an > enumeration in XML schema > > UBL E-business documents are generally intended to go > point-to-point between the individual business partners (via > ebXML Messaging services). Yes - I should have added that I was one of the early UBL members back in 2001 (you had no way of knowing that). > I don't think it would be at all practical to "filter" these > (numerous and voluminous) messages through a centralized Web Service. Oh, I wasn't thinking centralized - let's think more broadly, as in distributed/federated. > And it's generally only the two trading partners - or a > relatively small trading community around them - who've > agreed to use a particular extension or restriction of the > standard code lists. Most other folks using UBL - or even > OASIS or UN/CEFACT, the UBL standards people - would > probably remain blissfully unaware of any new currency codes, say. > Bosak's example entailed the hypothetical FQD (Free Iraqi > Dollar[sic]); forget for the moment that even if the "free" > Iraqi Dollar (or Dinar) ever were to see its way into > existence, ISO 4317 would require the first two characters of > the currency code match the ISO 3166 code of the country > issuing the currency (the notable exception being the euro, > EUR), resulting in something like IQF. Good points - perhaps UBL users could be furnished with one or more stylesheets that would do the trick? They could download these from the UBL site, perhaps - or perhaps the stylesheets could be "custom generated" through user entry into a simple form from the UBL site into which the user enters information regarding their code list extensions, and out pops a tailored stylesheet that could be inserted into the processing stream between them and their trading partners. Kind Regards, Joseph Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > Most folks in the world couldn't give a rat's ass about this > new currency and would have no need for the new code to be > used or validated. Only the two trading partners interested > in such a currency code addition would have to worry about > sharing a (small) schema that > (temporarily) overrode the notion of "CurrencyCodeContentType" > transparently allowing the addition of "FQD" to all the existing ISO > 4217 codes in the current "off-the-shelf" OASIS UBL > CurrencyCode-1.0 schema. > > William J. Kammerer > Novannet > Columbus, OH 43221-3859 . USA > +1 (614) 487-0320
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|