RE: FW: Conversations, or BP alignment with TR&P and Architecture

["Frank G. Pitt" <frankp@softed.com>]

> "Frank G. Pitt" wrote:
> > That's all very well, but if ebXML does not define some
> > semantics, and a protocol, or at least a message format,
> > specifically for operations involved in maintaining state
> > and audit trails, we'd better hope that its not core
> > functionality of the architecture, as these functions
> > will almost certainly not be interoperable between
> > implementations.>>
>
> That is not what the core competency of ebXML does.  Please read
> the Technical Architecture Draft specification.
> (lates version 0.6 - 0.7 pending)

I had already read 0.6, but I'll try to refer to it as I go through this.

If that's not what it's doing then OK, but then I'd be a little bit worried
by the description of the TRP section.

Perhaps this is where I should look next, as it seems from the description
in the TA doc that it's the message format that needs to support storing
audit information and handling all the transactional information.

I'll dig up the TRP documents and see what they say.

> > <SNI>Part of creating an architecture is validating that the
> > architecture will work for the core functionality. This may
> > mean more than just carrying out design of an example
> > application, it may involve deep prototypes as well.</SNIP>
>
> Agreed.  I have been pushing for this since day one.

Good. Sorry for being didactic.

<snip>
> > <SNIP>Repositories and registries are basically "nice to have",
> > but fundamentally unnecessary for B2B data transfer via XML.
> > </SNIP>
>
> Not in ebXML.   Agreed they are not necessary when you know and
> have agreed on a common vocabulary. When you don't have that prior
> agreement, they are one way to reference objects and object groupings ;-)

OK, I'll apologize in advance for perhaps getting you to rehash stuff that
everyone else knows, but let me put how I understand it, and you can then
point out where I'm misunderstanding.

There are several ways of making data interoperable, assuming a common
binary representation (i.e.: ASCII, XDR, XML or similar) of which I'll
mention the three I can think of off the top of my head :

1)Everyone uses their own format, but described in a common metadata format,
such as XML DTD or Schema. Each data file(message or whatever) contains a
URI referencing the DTD or Schema. Translation between formats requires
either high level AI or human intervention, though once translations are
created they can be stored on web sites and referenced by URI's also.
This is basic use of XML for B2B

2) As above but uses some core data elements and can build their formats
from those elements. Dublin Core is an example of the latter type, and
though I have little experience with EDIFACT, I believe that it works that
way too. From what I've read it looks like ebXML includes this concept.
Translation between formats requires lower level AI if only core data
elements are used, but may still sometimes require human intervention
because of problems in defining semantics of data elements.
Again transforms can be referenced once defined or can be machine generated
on the fly if you're lucky.

3) Everyone use a completely predefined data format.
   Obviously never going to work.


Assuming use of XML for raw transport, in both 1) and 2) referencing
existing transforms is the important part (even more so in 1)), because
DTD/Schema are always available with each data file.

There are probably several ways to discover transforms.  One is that the
sender, if they know who they are sending to, can include all relevant
transform URIs as a conditional processing instruction in the message.

The difficult case is when a receiver gets a message without a transform for
their data format.

If this is what repositories are being used for, tying two DTD/Schemas to
the transforms between them, then I can see that having a repository saves
individuals companies from having to either create on the fly, or
search for the particular transform by hand.

But I haven't seen any text on recovery of transforms, the TA doc talks only
about metadata, which, when using valid XML, are always referenced from the
document itself, so you don't need a repository to get them.

Of course, you might consider transforms to _be_ metadata, in which case
there's no real problem as long as people understand that metadata is not
just DTDs & Schemas.

ebXML (I understand?) will define the core data elements, but unless the
repositories do store transforms, I don't see them performing a _neccessary_
function.

Serving metadata from specified repositories is still a _useful_ function,
in terms of efficiency, reliability, and such.


Having said all that, there are some statements in TA 0.6 ( 2.2.6.b  and
4.f - j )that seem to imply actual executable code objects can be recovered
from the repository, and executed as a result of receiving a message. (Sort
of like a CORBA ORB )

If this is intentional(?) then repositories do become a lot more necessary,
but this seems a bit ambitious for this specification, as it implies a
response to an ebXML message may be the return of an executable with all the
attendant difficulties of properly encapsulating that in an XML message and
ensuring cross-platform capability

Again, I apologize if all this is obvious to other people on the list.

> Please read the Tech Arch Spec.  I would invite your input into
> our spec.

Thanks, I noticed the date for submissions on 0.6 has passed, so should I
wait for 0.7 ? I suspect, from reading the list, much of what I'd be likely
to say about 0.6 has already been said.

>Are you palnning on attendin the ebXML in August in SF?

No, sorry.
My time is booked for almost every day in August already, and it's hard for
me to justify a trip to the US from NZ without a client to visit<grin>.

Frankie


=======================================================================
= This is ebxml-architecture, the general mailing list for the ebXML  =
= Architecture project team. The owner of this list is                =
= owner-ebxml-architecture@oasis-open.org                             =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-architecture                                 =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-architecture myname@company.com              =
=======================================================================