[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Core Component Analysis - SWIFT's Comments
Bill, I have submitted comments (directly to Karsten) addressing among other things to the Datatype discussion. I asked that these comments be exposed when it was appropriate to do so. I specifically did not want my comments to become a show stopper in getting the document to public review. WRT Datatype, I would expect the document to address ebXML data types, which might include a datatype 'DateTimeInstant' for example. that ebXML datatype might well map to a specific XML Schema datatype. ebXML probably would not define a datatype 'Real'. Of course it might(will?) include a datatype 'Amount' which when rendered in XML maps to a 'Real'. The concrete mapping of ebXML datatypes to XML datatypes is in my opinion a task for Core Components to resolve. When all of the concrete mappings from ebXML data types to XML datatypes are defined, we may well find that some XML datatypes are not required to support the defined ebXML datatypes. Cheers, Bob Miller -----Original Message----- From: William J. Kammerer [mailto:firstname.lastname@example.org] Sent: Wednesday, January 17, 2001 11:20 AM To: ebXML Core Subject: Re: Core Component Analysis - SWIFT's Comments Nigel Wooden says "I know we are 'syntax neutral' but I believe we should provide an XML schema for each 'type' so that us poor users can pick up standard representations for our data when developing business documents for use in an ebXML environment..." I think I know what Nigel means - i.e., if XML Schema provides a datatype that seems to fit the bill for a basic core component - like a timeInstant, timeDuration or a float - then perhaps we should just go ahead and use the standard datatype rather than "invent" our own. Sure, constraints and patterns might be applied to derivations of these basic datatypes, but we may as well start with the fundamental data types provided by the Schema recommendation. In the meantime, I'm anxiously awaiting Bob Miller's comments on the Datatype section. Bob feels there's too much of that attitude of "if it's in XML [Schema], we must want it." I would've thought a standard generic white-bread "float" Schema primitive datatype could serve as a good base for really big quantities (e.g., as noted in http://lists.ebxml.org/archives/ebxml-core/200101/msg00062.html, for radioactivity measurements in Becquerels). I can't imagine Bob improving on what programmers pretty much expect of a floating point number - but maybe he wants to bust out the mantissa and exponent as separate core components. And I'm used to thinking of a date as just a date, for which the XML schema date datatype (ISO 8601) seems eminently suited. But this is probably a minority opinion, as evidenced by the ebXML Trading-Partners' Collaboration-Protocol Profile and Agreement Specification Version 0.1, which insists in Section 18.104.22.168 - Dates - that "A date is expressed in United States format, mm/dd/yyyy." See cpa-cpp-spec-0.1-interim.pdf at http://lists.ebxml.org/archives/ebxml-tp/200101/msg00060.html. Forget that XML Schema dates (CCYY-MM-DD) are sortable, or that their format makes more sense to the rest of Christendom. Like Ol' Blue Eyes, we just have to do it "My Way." William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC