OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[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:



<message type="catUpdate" content="remoteFragment" contentSKU="SKU111111">



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
XML Global Technologies, Inc.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC