[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: efficient XML
At 12:47 AM 3/11/00 +0100, Eckenfels. Bernd wrote: > Personally I am not sure which is better.. detached >routing, signatures, history, attachements or inlined. Inlined will >require less support from the tranporter, detached will require less >work on the documents, once transported to the endpoint. Perhaps both >options together (with a header which will include the transferred data >eighter as a link or inlined). This will work with XLinks inside >multipart MIME! This is an interesting and powerful concept. The delivery system could make its own decisions based on the content ,whether the data should be inlined or referred to as a resource. This may be useful with a company's catalog. If company A makes a minor change to it's product catalog, it can use the same message framework as other ebXML messages, and save company B bandwidth when it comes to telling them about the product change. I am directly involved in the development of an xml search engine, and have been playing a lot with XQL and XPath. I know that it is possible to use an XQL query to return just a piece of a large XQL file, so it would be possible to do something like this: <ebXML> ... <message type="catUpdate" content="remoteFragment" contentSKU="SKU111111"> <url>http://foo.com/catalog.xml?//Catalog/Item[10]</url> </message> ... </ebXML> Then, company B could just modify their copy of the catalog (if they are caching it). I can prove that something like that is feasible right now, aside from inherent problems with the DOM. __ Matthew MacKenzie -- Matthew MacKenzie CTO/VP R&D XML Global Technologies, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC