[ubl-comment] Re: UBL BIE Version 2.0

[Tim McGrath <tmcgrath@portcomm.com.au>]

hello again todd,  thank you for taking an interest

let me warn of against interpreting this material out of context (no pun 
intended).

if you follow the thread of this discussion you may note that this was 
an attempt to semi-automatically convert a section of the 'example core 
component catalog that Mark released November 5th' - so not too many 
surprises as to its content.  in actual fact, the UBL Library Content 
team is basing its initial content on taking the xCBL 3.0 vocabulary and 
identifying the BIEs and contexts (and by subtraction the core 
components) involved.  the library content subcommittee intend to 
present an ORDER document structure for comment by UBL Liaison groups 
(such as ebtwg-cc) in the 1st Quarter 2002.  

the structure being proposed here is a preliminary schema to allow us to 
move away from the two-dimensional 'excel spreadsheet' view and allow us 
to develop our conceptual BIEs in XML form.  if you are interested in 
pursuing the debate about what the naming and design rules of UBL should 
be, then you may be interested in the work of  the UBL Naming and Design 
Rules subcommittee (http://oasis-open.org/committees/ubl/ndrsc/).

if you have futher comments or questions about our work, then i 
encourage you to include the UBL comment list 
(http://lists.oasis-open.org/ob/adm.pl) as it exists for this kind of 
debate.


Todd Boyle wrote:

> Did you all see the release of UBL BIE Version 2.0
>  today on their mailing list archives?
> http://lists.oasis-open.org/archives/ubl-lcsc/200112
> http://lists.oasis-open.org/archives/ubl-lcsc/200112/msg00026.html
> http://lists.oasis-open.org/archives/ubl-lcsc/200112/bin00011.bin
>
> There seem to be about 209 words of vocabulary in their schema
> almost entirely from the example core component catalog that Mark
> released November 5th. I got half a dozen warnings those are purely
> examples and might be miles from whatever the UN CEFACT
> eventually agrees upon.
>
> Anyway, they did stuff like
>
>     <xs:complexType name="ChargePriceAmount" id="000127">
>         <xs:annotation>
>             <xs:documentation source="CC Definition" xml:lang="en">The 
> amount of money expected, required, or given in payment for 
> something.</xs:documentation>
>             <xs:documentation source="CC Basic or Aggregate" 
> xml:lang="en">Basic</xs:documentation>
>             <xs:documentation source="CC Remarks" 
> xml:lang="en">--</xs:documentation>
>             <xs:documentation source="CC ObjectClass" 
> xml:lang="en">Charge Price</xs:documentation>
>             <xs:documentation source="CC PropertyTerm" 
> xml:lang="en">Amount*</xs:documentation>
>             <xs:documentation source="CC RepresentationTerm" 
> xml:lang="en">Amount</xs:documentation>
>             <xs:documentation source="CC BusinessTerms" 
> xml:lang="en">Price Amount</xs:documentation>
>         </xs:annotation>
>         <xs:complexContent>
>             <xs:extension base="cct:AmountType"/>
>         </xs:complexContent>
>     </xs:complexType>
>
> I'm inclined to do it a little differently.  For one thing, I don't 
> think you can successfully import Core Comonents by dropping the dot, 
> without inserting any delimiter.  You have to expect naming collisions 
> in future if you do that. Also, I just baked the content model right 
> into the component. Did I do this "wrong"?
>
>   <xs:complexType name="GL.Amount">
>     <xs:annotation><xs:documentation>Monetary amount of an economic 
> event or accounting adjustment ...
>     </xs:documentation></xs:annotation>
>        <xs:sequence>
>              <xs:element name="Amount.Content" type="xs:decimal"/>
>              <xs:element name="AmountCurrency.Identification.Code" 
> type="xs:string" minOccurs="0" maxOccurs="1"/>
>        </xs:sequence>
>    </xs:complexType>
>
> As for all these long dotted names in shemas, I am "interested" in the 
> short "code" approach in the UDEF but in the long run, I really do 
> expect the messaging layer or other layer, will perform 
> tokenizing/compression and encryption on the fly.
>
> Fun!
> Todd
>
> .
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142