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: Problem statement regarding the ebXML Core Components model


Martin has written an interesting, on-point document. I couldn't agree more
with its conclusions, and I think you'll note that the DCN fulfills pretty
every single requirement mentioned by Martin. For instance, he talks at
length about roles and naming lists to reflect the relationship between
objects. The DCN does this today with its <list> element.

<Document>
   <list xsi:type='topics' name='subjectTopics'>
   <Topic/>
   </list>
</Document>

In the DCN, resources are allowed only to live in <list> elements where the
name of the relationship is established.

Also, Martin talks about designing the ebXML namespace to accommodate
object-oriented application software, something another note talks at length
about.

I need to reread his reasoning about roles, though. I came away thinking
that Roles and named relationships were the same thing in his mind. I don't
believe they are at all. The DCN defines a taxonomy for lists that is
separate from Roles -- in my view, that is where the proof of the pudding
is. I'd be interested to hear other views as to whether (1) Martin's memo is
a valid statement of ebXML requirements (2) whether the xCBL meets those
requirements and (3) whether the DCN meets those requirements, or some other
namespace out there.

One other requirement I'd mention concerns the _stability_ of the DTD/XML
Schema that is the ebXML schema. As you may know, xCBL has over 600 DTDs,
with more expected, with changes to each DTD expected I imagine. The DCN has
one DTD. With no additional DTDs expected. And few major changes expected.
DTD/XSD stability in my mind relates directly to the stability of stylesheet
code and application code. Basically because the applications will be
written to be  table-driven software, constructing tables/pulldown menu
lists from the RDFS dictionary. I say, parameterize the system, make only
one thing be evolving, and that is the dictionary of metadata, not the XML
elements used for data exchange.

> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Saturday, April 07, 2001 9:35 AM
> To: ebXML Core
> Subject: Problem statement regarding the ebXML Core Components model
>
>
> Martin Bryan's "Problem statement regarding the ebXML Core Components
> model" is now available online;  see the CEN/ISSS Electronic Commerce
> Workshop at http://www.cenorm.be/isss/Workshop/ec/;  select
> "Documentation," then the EC Workshop Document Lists for 2001.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>



[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