[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: re: CC Requirements : RE: Formal Protest from XMLGlobal.
David W: >The real long term solution is to move beyond TRP and toward W3C XP - but this also will need to wait until TRP sanctions the use of direct http/XML interchanges instead of MIME based SMTP protocols. David, I am glad you see this, as an emerging trend is to push this level of standards to W3C. However, the nonMIME package issue has certainly come up in the XP Workgroup, and noted. I can ask David Fallside (XP Chair, also in my internal department) the exact situation, but it is highly likely that this, if at all, would only be addressed in XP, not TRP given where ebXML is and schedule. Scott Hinkelman, Senior Software Engineer XML Industry Enablement IBM e-business Standards Strategy 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) email@example.com, Fax: 512-838-1074 David RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 12/28/2000 11:03:52 AM To: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com> cc: "''ebxml repository ' '" <firstname.lastname@example.org>, "'Martin Bryan '" <email@example.com>, "''Klaus-Dieter Naujok ' '" <firstname.lastname@example.org> Subject: re: CC Requirements : RE: Formal Protest from XMLGlobal. Message text written by "Nieman, Scott" >2) There seems to be a requirement to be able to resolve entity references directly from a DOM parser (second and third paragraph); interaction with the registry currently requires TRP which was a StC decision. At this time every request to the Registry needs authentication. RR discussed session and state management which could potentially assist direct DOM interaction with the Registry.< >>>>>>>>>>> Scott, In the PoC in Tokyo content was not being passed via the payload - but as a URL. Therefore retrieval of physical content was being done completely outside of TRP since the RR DTD's did not contain any ability to encapsulate XML content as part of the payload. It's not clear this limitation of the original DTD's has been removed or remedied. There is still a contridiction in the latest spec's - since they state that the get**** functions do not require authentication - when in fact from your note above they clearly do. I submitted an alternate DTD structure in Tokyo that implemented all this - but that was rejected; and it appears the issues still remain. A single consist DTD that works for all current and future query paths without structural extensions can greatly simplify the implementation and maintenance dynamics here. Given the time constraints you are working to - I'm sure you now have no room to correct all this - beyond some bandaiding to get thru the Vancouver PoC. The real long term solution is to move beyond TRP and toward W3C XP - but this also will need to wait until TRP sanctions the use of direct http/XML interchanges instead of MIME based SMTP protocols. I'm looking forward to getting out from underneath time-driven expedient engineering as the sole criteria. Thanks, DW.
Powered by eList eXpress LLC