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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: RE: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Pro ject


Title: Message
There is an implicit premise here Arofan: that some _action_ is necessary on the part of the UBL design team in order to "support" generic headers.  That's where I lose the trail.  Isn't it true that if someone wants to define some "generic envelope" in XML that they can just do that and that and any old UBL document can just be added as an element inside that envelope?  Same for any XML-based document standard right?  Envelopes go on the _outside_ right?
 
-Bill
-----Original Message-----
From: A Gregory [mailto:agregory@aeon-llc.com]
Sent: Friday, February 21, 2003 5:10 AM
To: ubl-lcsc@lists.oasis-open.org; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project

Folks:
 
I haven't been able to send e-mail for a few days, but now that I can...
 
I guess I am very uncomfortable with the thought that we will be designing documents that are not suitable for use on systems that have large legacy components. Just because some older architectures were not as clean and wonderful as the new ones we're coming up with in ebXML, etc., doesn't mean that users will be moving to newer architectures as the standards are released. Most companies have to deal with some kind of gateway architecture that combines the old and the new, including EDI and possibly some of the newer stuff.
 
This is why I think generic header is important - because it helps people implement a newer architecture while still being compatible with legacy systems that are somewhat limited.
 
UBL is supposed to be immediately useable. I would guess that the number of legacy implementations requiring (or usefully having) some type of control ("envelope") data in the message still vastly outnumber pure ebXML-based architectures. We're not in the business of dictating architectures to anybody, just making useful messages that will work with different types of architectures.
 
I think this argues in favor of providing places in our documents where people can put generic header information if they need to.
 
Cheers,
 
Arofan


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


Powered by eList eXpress LLC