[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Abstract Type vs. Type Code
Mike, my understanding agreed with QRT and Klaus was that the Initial Catalogue of Core Components is not a specification. Comments could be accepted, but against the structure rather than the content of the document. The reason being is that these components discovered are by no means definitive or complete. Kind regards James Whittle E Business standards executive Tel. No. 44 (0)20 7655 9022 Fax No. 44 (0)20 7681 2278 10 Maltravers Street, LONDON, WC2R 3BX. www Address: www.e-centre.org.uk <http://www.e-centre.org.uk> e-mail james.whittle@e-centre.org.uk <mailto:james.whittle@e-centre.org.uk> Best business practice in a digital age. Disclaimer Notice The above information is intended only for the person(s) or entity to which it is addressed, and may contain confidential or privileged material. Any use (including retransmission or copying) of this information by person(s) or entity other than the intended recipient is STRICTLY PROHIBITED. If you are not the intended recipient of this transmission, please would you contact the sender and delete the material from any computer. The sender is not responsible for the completeness or accuracy of this communication as it has been transmitted over a public network. Any views or opinions are solely those of the author, and do not necessarily represent those of e centreUK. All third party rights are duly acknowledged. e centreUK is the trade name of the Association for Standards and Practices in Electronic Trade - EAN UK Limited, and is registered in the United Kingdom (Registration Number 1256140). © 2000 All Rights Reserved -----Original Message----- From: Mike Rawlins [mailto:rawlins@metronet.com] Sent: 15 March 2001 23:01 To: ebXML-core Subject: Abstract Type vs. Type Code This is the first of a few questions that are intended to help me understand the group's thinking before I make formal comment on the specifications. If any of these are old ground to you, please forgive me and help me to get up to speed. In reviewing several of the items in the Appendix A spread sheet there are several that have a type code. (BTW, is this part of the official submission, even if not an official spec? I don't see it on the web page for specifications for review), For example: Party.Details has a Party Type. Identification.Details which contains a code value and text. I suspect the intended use, but I would like verification. If I use an OO-analysis analogy, it would be like having a Party object with an attribute of type Seller, rather than having a Seller concrete class that is a descendent of a Party abstract class. I know you are trying to stay away from syntax issues in the analysis, but there are syntax implications that have to do with your intent. If we take an example XML instantiation, do you intend something like: <PartyDetails> ... <PartyType> ... <CodeDetails>SE</CodeDetails> ... <PartyType> ... <PartyDetails> instead of in the schemas declaring PartyDetails as a complexType, with a Seller element being a party, and having in an instance document: <Seller> ... </Seller> It seems to me that in both cases you are intending the former rather than the latter. Please confirm. -- Michael C. Rawlins, Rawlins EC Consulting http://www.metronet.com/~rawlins/ ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC