Re: Document Conflict

[Mike Rawlins <rawlins@metronet.com>]

I would like to point that this is not the only problem with the catalogue -
that is one of the reasons I think this is a show stopper issue.

A sampling of the other problems:

   * Dates in general - location.available.date seems as if it should be a basic
     entity with a representation type of DateAndTime.   However, it is
     represented as a reuse of the aggregate dateandtime.details, which is
     itself an aggregate of two more aggregates of date.details and
     time.details.  When we look at date.details, we finally get to a basic
     information entity "date", which seems to complicate the application of
     naming conventions because the property name is the same as the
     representation type is almost the same as the class name.
   * Time, code, text, and identifier have similar problems.  They are listed as
     representation types, yet are shown in the catalog as aggregates composed
     of basics

The Appendix A in the catalogue needs serious rework in this regard, and we
can't do it without a clear definition of the purpose of representation types
and detailed specification of each type.

Mike

Martin Bryan wrote:

> The list of Representation Types in section 6 (line 195) of the Naming
> Conventions for Core Components Version 1.02 conflicts with the Core
> Components Catalogue in its defintions of DateAndTime. The Table has two
> entries, Date and DateAndTime. The Catalogue has two Basic objects, one for
> expressing dates and the other for expressing time. It contains no mechanism
> for entering a complete ISO 8601 compliant date and time entry as a single
> object as the current definition requires the use of two aggregates, one to
> define the date and the other to define the time. This is against the spirit
> of the ISO 8601, which gives preference to a single DateAndTime
> specification wherever both are to be specified.
>
> Martin Bryan
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/