[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen ericHeader' Project
Comments inline. Burdett, David wrote: > The original use case for including the "header information" in the > payload is to support some of the existing translation/mapping software > tools that can only handle one "document" at a time. They are unable to > support message information in a header and simulataneoulsy handle the > document itself. Copying the information into a header in the document > solves this problem. This is really no more than a different > representation of the message information. > > But is this the right way of solving the problem? > The GH team has not been concerned that the GH solution is "the right way" to solve all problems with interfacing the business application with the remainder of the middleware stack. That is a religious issue, and there are many sects professing to know the "right way." These include CORBA, RMI, JMS, MQ, DCOM, .NET, and untold others. I personally do not think it is very useful to worry about endorsing/describing all those integration technologies. I also question whether it will advance the real-world integration situation by inventing yet another alternative to all those technologies which is the ebXML "right way." I think that is a certain recipe for impeding the deployment of ebXML solutions. Obviously the GH is a lower budget way for integration through the file system and will be of interest to those people interested in preserving their applications while needing to dump their data into an XML format and down the stack, over the wire, to their collaborators. So I think that David is really on a fishing expedition here. This is not the "right" question to raise. > The questions we need to answer include: > 1. Does creating a standard set of header information help? I think > the > answer is yes at it reduces development cost for *those instances* where > you have a business or technical need to do it. > It also allows a "syntax decoupled" approach to saying what minimally is available for interfacing EDI/XML business document serializations with the gory underworld of middleware stacks. It also seeks to define a namespace and infoset for XML usage. Also a schema is a probable work item. > 2. Should such a header be a standard (optional) part of each message? > I > don't think so since in many cases it will not be needed at all I don't get this, David. If it is optional, doesn't that address your apparent objection that "in many cases it will not be needed at all." I thought that was what optional means... One real worry is that people who insert the XML for GH be able to extend their documents to insert the XML elements and still have the XML document validate against their schema for the business document. That could be taken care of at document design time by means of appropriate construct for extensibility. But even if that small amount of standardization fails, a local copy of a BOD/BIE unit could be made that allows validation against that. So making provision for a GH extension is a "nice to have" not a necessity. > 3. Should you define a standard way of including it in a message when > needed? I think you should as sometimes you will need it. In this case > handling it using XML Schema and its extension mechanism makes sense, I > think. > OK, I think I agree with this, as I would save hacking on a local copy of a schema in many cases as previously mentioned. > Bottom line, message metadata information should normally go in the > header and not in the document but a method of putting or copying the > information into the message itself should be defined for use when needed. > The data in a GH won't necessarily or even normally be copied into a message SOAP header block itself. Translators would not do that, for example.
Powered by eList eXpress LLC