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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

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


Subject: Re: OTA Tag name rules


IMHO -

For speed reasons the version should be part of the tag - but only at the
logical unit level where we want to maintain version control.

Version should be for noun (core components) and verbs (business process).

- Bruce

----- Original Message -----
From: "David RR Webber" <Gnosis_@compuserve.com>
To: "Christopher Ferris" <chris.ferris@east.sun.com>
Cc: <ebxml-architecture@lists.ebxml.org>
Sent: Friday, September 29, 2000 6:45 PM
Subject: Re: OTA Tag name rules


Message text written by Christopher Ferris
>>
 > > I agree. Adding version numbers to tag names is not optimal.
> > >
> > > Can we not add the VersionNumber as an attribute - something like
> > ><Cust.Pay.CreditCard VersionNumber="1.0">, so that whoever wants to
use
> > >version numbers can use them and it does not break the stylesheets et
al.
>
> And common coding style across ebXML DTDs should be discussed where?
>
<<<<<<<<<<<<<<<<<<<

This is part of the GUIDE work too.   The Classification schemes within
ebXML
should NOT be arbitrary (if you want that - that's the OASIS model for
generalized content).

We know we are going to have a descrete base set - namely BP, CC, TRP, TPA
RegRep, for starters - that define consistent formats that conform to the
ebXML Model.   Then based on those is the interoperability standards and
GUIDE is an approach there.   RegRep does also require compliance to
certain factors to make the Registry work optimally too.

I'm planning to completely revise GUIDE and produce a V2.0 that
incorporates
a clearly compliant ebXML model - and maybe this is part of the answer
here - to have an ebXML working group on this - I would strongly suggest
this be POST Tokyo PoC however - as all the pieces that go into this
will then be MUCH better understood by the individual teams that need
to provide input.

However - NOT trying to be smug here - providing the GUIDE work was
always intended to give ebXML a start point from which to build a
consistent framework that endusers can follow to accurately assemble
ebXML systems.

GUIDE has been submitted to ebXML - its there - please feel free to
revisit - revise - borrow - and re-purpose as makes sense.  I believe
you will find a lot of good things there already.

Thanks, DW.



[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