[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: re "What is a R"
David Webber wrote: | Message text written by Terry Allen | > For | ebxml purposes, which I take to be the storage of schemas | for defined e-commerce documents, the decomposition makes sense = | | (although for e-commerce in general there will be some documents | that are treated as attachments and the schemas for which needn't | be stored in this repository). | <<<<<<<<<<<<<<<<<<<<<<<<<< | | Terry, = | | | This is way off beam. The function of the XML repository for ebXML is | to faciltiate B2B and B2C commerce thru electronic means based on | XML as the underlying syntax. The audience is broad business end | users; not specialized MIS professionals. I don't understand how those remarks relate to what you quote from what I wrote. We're talking about whether it is necessary to describe the full content of a schema (in this case, in MOF or XMI), or store the schema as a blob (which will suit for many XML purposes), NOT what the audience is for particular views of the metadata about those schemas. Please check and be sure you understand the purpose of the document I referred to, http://objectrepository.homepage.com/metalevels.html | Just as EDI has IG (implementation guidelines) to assist END-USERS | in locating applicable information and transactions to fulfil their | business | functional needs between them and their trading partners - so too the = | | ebXML XML repository should serve as a portal to enable practitioners | within a field | (accountants, adminstrators, business people) to quickly, = | accurately and easily locate, use and contribute too the information | and process base. | | Therefore, the critical functionality is NOT all the wiring such as = | | X3.285, SC32, X3L8, ISO 11179, UML, which only serve in = | | obscuring the business operational and simple functional facilitation. | A better analogy is a simple Category/Section and lookup, retrieval | system based on business purpose. Directed searching and = | | human custodians, (as discussed at length in the XML/edi group | document on Repositories) can far surpass the capabilites of = | | robot and agent classification systems. We're talking exactly about the wiring here. Your paper doesn't. | Next time you walk into your local library to find a book - would you | want to be confronted by an indexing scheme based on a hybrid | meta-topic based rendering of the vectors from a point determined | analysis of the surface mapping of the information space derived = | | from the canonical Dublin-core based parsing of the electronically | scanned book content of the whole library, OR would you rather: | | a) Ask the information desk? | b) Go to a simple classification by category and section that the | librarians have assembled as they add new books to = | | the shelves? Of course there must be a human-readable interface to the stored objects, but it must be constructed from the metadata for those objects. As you mention library classification schemes, you might want to look at corc.oclc.org which allows navigation of the quite complex metadata librarians actually use. In the document I was commenting on, the point of departure is the modelling of business processes, which the CEFACT TMWG has embraced. If you want to take issue with that decision, you'll probably have to show them how you can get the results they think they need without the machinery they think they need.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC