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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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


Subject: RE: Getting Back to Basics - How to describe Dates and Times andEvents?


John McClure said,
> I'd support more going the extra INCH to an RDF statement of type.
> Presuming that the type is defined by an RDF
> Schema statement, which I hope it is, decorated as it can be with business
> rules stated using DAML (DARPA's Actor Markup Language) and RuleML.
>
> <docRef
> rdf:type="http://www.ebXML.org/Messages/Invoice">ABC-12345</docRef>
>
> In RDF, this is equivalent to
>
> <docRef>ABC-12345
>   <rdf:type rdf:resource="http://www.ebXML.org/Messages/Invoice"/>
> </docRef>

John,

Why is rdf better for the SME than the ebXML registry?  The URI syntax
Martin suggested is completely unambigous.  RFC 2396.  The ebXML
registry provides a unified repository for *all* of the layers of
the ebXML protocol stack, sitting in a database, with all of the
necessary query and interface decisions optimized for the requirments
of various applications and populations of users.  Having it all
in one place is much more efficient in terms of security, bandwidth,
version control, and many other issues.

There is a need for realism here.  Nobody in ecommerce is going towards
RDF.  They are all going towards point solutions such as XML/biztalk,
or sticking with EDI.  Here in ebXML we are *trying* to get people to
consider registries (relational databases containing metadata).

I am using Martin's syntax in my Code List object, in the software,
but not storing it on every row of the GL or the GL schema.

First of all, the way we use Invoice number in a GL is just to store
the invoice number, not the invoice itself.  IMO, the URI to go find
the document format is a detail or attribute of a document type, if
a system wants to go that far.  It is not a field in the transaction row.
This goes back to the natural boundaries of a GL.  A GL is that minimum
necessary view of transactions for consolidated receivables and payables,
for cash balance/cash flow, for tax and financial reporting.  If you
start talking about storing the business doc. itself, you are replicating
what is being done on the business system (sales, purchasing, payment etc.
modules.)

Also- there is little point in URI syntax until there is a registry online
and accessible from the internet, with a set of core components and
business documents. This could be ebXML or UDDI or any other consortium.

I fervently wish that somebody would built the ebXML RegRep, and fix
it to include the most important service of all: a shared transaction
repository.  An STR is a single place for storing the shared elements
of any 3rd party economic exchange.  They are commonplace in securities
and derivatives markets, and apparently in some exchanges like CIDX.
A bank is like an STR.  Banks are exceedingly efficient, at internal
transfers but inefficient at external ones.

ebXML is trying to perfect systems of replication analogous to
two-phase commit.  Which is better?  Replication or shared repository?

TOdd


> Todd suggested:
>
> > <docRef>
> >   <docType>Invoice</docType>       (required)
> >   <docNum>ABC-12345</docNum>       (required)
> > </docRef>
>
> Martin would prefer the much simpler
>
> <docRef docType="http://www.ebXML.org/Messages/Invoice">ABC-12345</docRef>







[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