Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Vocabularies for Large Systems - 3 Philosophically Dif
 [Stepping up on Strategist Soapbox] I think this all comes down to business and technical requirements in a given situation, and cannot be defined as a heuristic. In considering the three proposed approaches (copy/pasting here for reference): a. Create multiple, simple XML vocabularies. b. Create a single, simple XML vocabulary that is used in multiple ways. c. Create a single, large, complex XML vocabulary. I can see potential cases for all 3 - it really depends on the needs of the particular situation. [Stepping down from Strategist Soapbox] I will assume here that a "system" can expand beyond an organization's boundaries and include its trading partners - i.e. it need not be confined to an organization internally (not in December 2004). Regarding the 3 approaches: For (a): Consider a system that has multiple aspects, or sets of functionality requirements, each of which operates according its own simple XML vocabulary. For example, a loan-processing system may have an XML vocabulary for the loan application, and another for its interactions with credit bureaus. It may be required by a given credit bureau to use the credit bureau's own XML vocabulary for interacting with it - in which case the loan-processing system would need to translate tags and contents as necessary. This is a case where there are 2 simple XML vocabularies. I realize that in this case, the same organization did not create both vocabularies - but I'm sure there are cases in which that may be necessary. In this case, the business and technical requirements called for "bridging" the 2 XML vocabularies, because the loan-processing system vendor could not dictate to the credit bureau that the credit bureau use their XML vocabulary for information exchange. For (b): Here we are dealing with vocabularies that are more general in nature - that is, they perform a function that is not specific to any business domain, and that is really "context-neutral". An example of this would be if an organization decided (for whatever strange reason) to create its own proprietary messaging format for a given system, rather than using SOAP (for example). Consider further that a system has the ability to extend the messaging format with "custom" tags as needed. The set of tags used in the "base" messaging format would constitute an XML vocabulary that is used in multiple ways. In this case, the organization's business and technical requirements drove them (for some strange reason) to create their own proprietary messaging format. For (c): Consider the same situation as (a), but where the same vocabulary is used for the loan application and credit bureau information. Perhaps both systems use the same overarching standard vocabulary - i.e. one that covers both the loan application and the credit bureau information. We will assume that this standard vocabulary is "large" and "complex" (as per the approach description above), but that is of course subjective. In this case, the business and technical requirements called for using a common vocabulary, because one was available and applicable. Or perhaps it just so happened that the loan-processing system vendor and the credit bureau happened to use the same standard vocabulary. Kind Regards, Joseph Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > -----Original Message----- > From: Roger L. Costello [mailto:costello@m...] > Sent: Sunday, December 12, 2004 2:54 PM > To: xml-dev@l... > Subject: XML Vocabularies for Large Systems - 3 > Philosophically Different Approaches > > Hi Folks, > > I am interested in hearing about the nature of XML > vocabularies that are being created for large systems. I am > particularly interested in hearing from people who have been > successful in using simple XML vocabularies to implement the > complexities of varied data in large systems. > > Allow me to explain further... > > DEFINITION > > XML Vocabulary: an XML vocabulary is the collection of tags > that is used to markup data. For example, this data: > > Borders Bookstore, 20 Boylston Avenue, Boston, MA, 01320 > > may be marked-up using this XML vocabulary: > > <Addressee>, <Street>, <City>, <State>, <Zipcode>. > > This later constitutes an XML vocabulary for U.S. Mailing Addresses. > > SYSTEMS OF INTEREST > > My interest is in large systems, where the variety of data is > large, and in the nature of XML vocabularies for such systems. > > ISSUE - NATURE OF XML VOCABULARIES FOR LARGE SYSTEMS > > I identify three philosophically different approaches to the > creation of an XML vocabulary for a large system: > > a. Create multiple, simple XML vocabularies. > b. Create a single, simple XML vocabulary that is used in > multiple ways. > c. Create a single, large, complex XML vocabulary. > > Let us examine each of these approaches: > > a. Create multiple, simple XML vocabularies > > In daily life we encounter many analogues to this > approach. For example, > the postal service has its own simple vocabulary - > addressee, street, > city, state, and zipcode; a restaurant has its own menu > vocabulary - > appetizer, entree, dessert, and side dishes. I am sure > that you can > think of many other examples. We live in a world filled with many > simple vocabularies, and (for the most part) we are able > to move about > and function adequately with this multiplicity of simple > vocabularies. > > Likewise, in creating an XML vocabulary for a large system > one approach > is to create multiple simple XML vocabularies. > > b. Create a single, simple XML vocabulary that is used in > multiple ways > > Consider the XML vocabulary called RSS. It is a simple > XML vocabulary. > Despite its simplicity it is very popular and powerful. Likewise, > Jabber is a very popular and powerful simple XML vocabulary. > > A second approach for the large system is to create a simple XML > vocabulary that is used in multiple ways. For example, you may > have an RSS feed that captures one aspect of the large system, > a second RSS feed that captures a second aspect of the > large system, > and so forth. The combination of RSS documents is used to > collectively capture all the data complexities in the large system. > > c. Create a single, large, complex XML vocabulary > > All the complexities of the large system are implemented > by creating a > single, large, complex XML vocabulary. > > QUESTIONS > > Have you implemented a large system? Have you created an XML > vocabulary for a large system? Which of the above three > approaches did you take? I am particularly interested in > hearing from people who have used simple XML vocabularies > [approach (a) or (b)] to achieve all the data complexities in > a large system. > > /Roger > > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org > <http://www.xml.org>, an initiative of OASIS > <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > > 
|
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
|
|||||||||
