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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-sbsc message

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


Subject: Re: [ubl-sbsc] Specification approach for UBL 2 SBS


Apologies that my copying and pasting of the JPLSC comments didn't
work very well in that last posting so here is the whole document

All the best

Stephen Green



Quoting stephen.green@systml.co.uk:

> Good news...
>
> I've been working on the next draft SBS based on the latest pro-PRD2
> UBL 2 draft schemas and have a set of schema files which all work from
> the same Common schema modules.
>
> Also, we have received some excellent comments from JPLSC/ECOM based
> on their gap anaylsis against the ECOM schemas for SMEs. The following
> is an extract regarding the SBS (submitted here with permission; many
> thanks to JPLSC):
>
> "2.2.2 Mapping to SBS
> 37% BIEs (including Direct mapped BIEs and substituted mapped BIEs) of
> the Manufacturing SMS Business Document are mapped to SBS V1.0.
> 64% BIEs (including not mapped in SBS and not mapped in UBL) are not
> mapped to SBS V1.0
> (1)Mapping impossible BIEs in SBS (Indispensable and semi indispensable)
> (a)Indispensable BIEs
> BIE description in Japanese
> BIE description in English
> Comments
> ??????
> Buyer Identification
> There is no PartyIdentification in SBS.
> ??????
> Seller Identification
> There is no PartyIdentification in SBS.
> ????????
> Buyer item identification
> There is no BuyerItemIdentification in SBS.
> ????????
> Item name
> There is no Name in SBS.
> ????
> Delivery address ID
> There is Delivery Address, but there is no ID in SBS.
> ??????
> Delivery quantity
> There is Delivery, but there is no Quantity in SBS.
>
> (b)Semi indispensable BIEs
> BIE description in Japanese
> BIE description in English
> Comments
> ???????
> Buyer party contact ID
> There is Contact in SBS, but there is no ID in SBS.
> ????
> Buyer lot number identification
> There is no LotIdentification in SBS.
> ??
> Item version number
> Capable to be substituted by AdditionalItemIdentification of Item.
> There is no AdditionalItemIdentification of Item in SBS.
> ????????
> Physical attribute ,  measurement dimension, and others
> There is no BuyerItemIdentification in SBS.
> ????
> Inspection method code
> There is no InspectionMethodCode in SBS.
> ??????
> Delivery ID
> There is Delivery, but there is no ID in SBS.
> ??????????
> Buyer barcode information
> This BIE is used to use AdditionalItemIdentification.
> There is no Additional ItemIdentification in SBS.
> ????
> Tax type code
> Tere is no TaxCategory in SBS.
> ??????
> Payment means code
> There is no AllowanceCharge in SBS.
> ????
> Tax total amount
> There is no TaxTotalAmount in SBS.
> ???
> Total amount including Tax.
> There is no ChargeTotalAmount in SBS V1.0.
>
> (2)Evaluation about SBS
> It will be difficult to adopt SBS in Japanese marketplace, because
> many BIEs are not included in SBS BIEs. The mapping percentage of
> Japanese major business document to SBS V1.0 is small comparing
> fullset UBL V2.0.
> We would like to make UBL subset to Japanese marketplace based on the
> fullset UBL V2.0.
> If SBS V1.0 would be revised based on UBL V2.0, the mapping percentage
> of Japanese major business document to SBS would be much bigger.
> The birth and background of both UBL SBS and Japanese Manufacturing
> SME business document is different each other. Therefore, it will be
> natural to think that these two business documents have many
> differences."
>
>
> I have sought to incorporate at least the 'indispensible' items into the
> SBS.
>
> I hope to send the schema files soon, once I've checked them through.
> I'm also working on examples which may be af value for the PRD2 UBL 2package.
>
>
> All the best
>
> Stephen Green
>
>
>
>
> Quoting stephen.green@systml.co.uk:
>
>> Thanks, Ken, for the suggestion.
>>
>> I/we'd typically have to produce schemata anyway so making them
>> suitable for publication seems good to me.
>>
>> I'd not really want them to be normative though, unless we can do
>> so without ruling out use in instances (either with TP agreement but
>> without special agreement being necessary) of non-subset-but-valid-
>> UBL elements. If it were necessary for some reason to make them
>> either normative or usable in agreements, I'd say we need a way to
>> add a normative URI (as we have in UBL 1.0 SBS for the 'XPaths'
>> files.
>>
>> All in all it's a lot of work though so we'd need to factor in what
>> is achievable and how long we have.
>>
>> All the best
>>
>> Steve
>>
>>
>> Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:
>>
>>> Fellow members of UBL SBSC,
>>>
>>> I would like to propose to the SBSC that we as a group consider a
>>> different approach towards specifying the UBL 2 SBS than was done for
>>> the UBL 1 SBS.
>>>
>>> As you recall, we specified UBL 1 SBS exclusively through XPath files
>>> that catalogued the information items in the subset.
>>>
>>> In the development of UBL 2 there has been feedback regarding the
>>> perceived necessity, let alone convenience, to some of having schema
>>> expressions of the subset.  This would be a set of schemas for the same
>>> namespace but specifying a lesser set of optional constructs, just as
>>> was specified by the XPath files, but doing so using XSD.
>>>
>>> I've posted some thoughts of mine regarding UBL customization       
>>> approaches here:
>>>
>>> http://lists.oasis-open.org/archives/ubl/200606/msg00109.html
>>>
>>> Please let me know your thoughts about treating UBL 2 SBS as a UBL
>>> customization effort such that we produce an SBS set of schemata, as
>>> described in chapter 8 of that paper referenced above.  As I've
>>> indicated in that paper, I propose using XPath files to conclusively
>>> prove through exhaustive enumeration that each and every possible
>>> information item and cardinality of the SBS schemata is an information
>>> item allowed in UBL.  I don't see the SBS needing any extension
>>> elements, only needing to elide optional elements.
>>>
>>> Because of the push for code lists and other UBL 2 issues (and writing
>>> my UBL tutorial) I have yet to write the code utilizing XPath files to
>>> prove the exhaustive enumeration, but this is high on my "to do" list
>>> once we get into UBL 2 review.
>>>
>>> Nevertheless, I thought it important that we should start talking about
>>> UBL 2 SBS now in order to get ideas on the table for consideration.
>>> Hopefully for UBL 2 SBS we would be able to subset the common library
>>> expressions and each of the document types such that we have a single
>>> suite of XSD expressions of the normative subset of UBL 2 that is the
>>> Small Business Subset.
>>>
>>> Please let me know what you think.
>>>
>>> . . . . . . . . . . . . Ken
>>>
>>> --
>>> Registration open for UBL training:    Montréal, Canada 2006-08-07
>>> Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
>>> Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
>>> World-wide corporate, govt. & user group UBL, XSL, & XML training.
>>> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
>>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
>>> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
>>> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
>>> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


Comments to UBL SBS by UBL JPLSC.doc



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