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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: [ubl-dev] Question regarding item specification in Catalogue


John,

I also think you can split things between what you communicate in the catalogue and what you receive in a order.

So in the catalogue you can specify all the options that are possible under ItemInstance using the additionalItemProperty.
And then in the Order/OrderLine/LineItem/Item/ItemInstance/AdditionalItemProperty the buyer only returns those details that are required for that specific orderline. You can go all out fancy with the ItemPropertyGroup to split the various properties etc etc ..

I would suggest you use the ItemSpecificationDocumentReference on Item level in your catalogue to point to a URL where you can explain all the possible options they use in their order etc etc.

(and thinking out loud, that might be even bettter then using ItemInstance in a catalogue, because by definition an ItemInstance can not appear in a catalogue I think)

But also think about this:

How are your buyers/customers going to work with this? Do they have to create a specific interface for orders for you specifically? and can they afford to invest in building this?
Even with UBL being a standard does not mean that all implementations are able to use all possible UBL elements.
So maybe your customers do not have a UBL receving interface that can deal with ItemInstance information in the UBL catalogue document
Or their ERP system they use for creating the actual order can not handle those additionalItemProperties with the correct values

So there is always a tradeoff between what is technically possible and what is practically possible.
If the buyer is a large customer where it makes sense to create a one off interface for your business only .. then they will certainly spend the money if there is a sound business case.
For the once in a month customer, not so much :-) 

Kees Duvekot

p.s.
I'm just sharing what I'm thinking about based in the provided information, that does not mean there are more possible options.


 
________________________________________
Van: John Grekso [JGrekso@DSSI.net]
Verzonden: vrijdag 19 februari 2016 22:55
Aan: G. Ken Holman; ubl-dev@lists.oasis-open.org
Onderwerp: RE: [ubl-dev] Question regarding item specification in   Catalogue

Hi Ken,

Thanks again for the suggestions.  I definitely appreciate the perspective you have provided.  I'm not sure which way we will go but this certainly has given me some things to think about and also a better appreciation for UBL.

John

-----Original Message-----
From: G. Ken Holman [mailto:g.ken.holman@gmail.com] On Behalf Of G. Ken Holman
Sent: Friday, February 19, 2016 2:48 PM
To: John Grekso; ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] Question regarding item specification in Catalogue

At 2016-02-19 18:58 +0000, John Grekso wrote:
>In terms of representing any rules about the value that can be
>specified for the property would something like this seem reasonable?
>
>Example:  a shirt needs a string that represents the name where the
>name can be up to 30 characters
>         <cac:ItemInstance>
>                 <cac:AdditionalItemProperty>
>                         <cbc:Name>Name</cbc:Name>
>                         <cbc:NameCode>NAME_CODE</cbc:NameCode>
>
><cbc:TestMethod>^[0-9a-zA-Z\s]{1,30}$</cbc:TestMethod>
>                 </cac:AdditionalItemProperty>
>         </cac:ItemInstance>

I guess I need more information.  Can you assume (by mutual agreement with your trading partner) that the test method is expressed as a regular expression?

>There is a TestMethod element in the item property.  Based on the
>example in the documentation I'm not sure if this would be an
>appropriate usage.

Interestingly, languageID is available to use.  I wonder if you could do something like the following, especially since regular expressions are a kind of language of the character string:

   <cbc:TestMethod languageID="regex">^[0-9a-zA-Z\s]{1,30}$</cbc:TestMethod>

per:

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#UDT-Text.Type

Certainly the above would pass schema validation, and the recipient of the document would know what to do with the character string content.  It is just identifying a computer language instead of a human language.  I put it out to my committee colleagues who are listening on this list as to whether or not this is inappropriate.

So ... I'm assuming that in the catalogue you would have the item property element without a value indicating to the recipient ordering the item to have it filled it out with a value when returning the item information as part of the order.

You would probably want to populate <cbc:ImportanceCode> to indicate to the recipient if the value is optional or mandatory (or something in between):

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_ItemProperty.Details

>Another option I had for the string length would be to use the
>RangeDimension element with a unitCode of "CHAR" or something to denote
>min and max lengths.  This feels like it would be stretching the
>concept of what Dimension is meant to represent.

Well, it covers the length of the string value, but not the content, and I think the semantic is a limitation of the content expressed by the value not the expression of the value.  But if length is all that is important to you I think it might work.  I confess, though, that it feels wrong to me too.

>Example:  a title needs to be selected from a predefined list of Mr.,
>Mrs., and Dr.
>         <cac:ItemInstance>
>                 <cac:AdditionalItemProperty>
>                         <cbc:Name>Title</cbc:Name>
>                         <cbc:NameCode
>listURI="http://title-code-list.gc";>TITLE_CODE</cbc:NameCode>
>                 </cac:AdditionalItemProperty>
>         </cac:ItemInstance>
>
>In this case the validation would come using the provided code list to
>validate the selection.

I would write that differently because the <cbcNameCode> is the codified expression of the property name, not the property value.  You've inappropriately constrained the property name code by a list of property values.  So you need at least this, which is the same but without the attribute:

        <cac:ItemInstance>
                 <cac:AdditionalItemProperty>
                         <cbc:Name>Title</cbc:Name>
                         <cbc:NameCode>TITLE_CODE</cbc:NameCode>
                 </cac:AdditionalItemProperty>
         </cac:ItemInstance>

The property value always goes into the <cbc:Value> element.  The question is, again, how to express the constraints on the property value.

Typically coded values for genericode are expressed out of band in the context/value association file that is applied as part of validation.  The supplied demonstration UBL 2.1 CVA file is in here:

   http://docs.oasis-open.org/ubl/os-UBL-2.1/cva/

The fragments would read along the lines of:

   ...
   <ValueList xml:id="titleCodeList"
              uri="/path/to/title-code-list.gc"/>
   ...
   <Context values="titleCodeList"
            address="cac:AdditionalItemProperty[cbc:NameCode='TITLE_CODE']/
                     cbc:Value"/>
   ...

But if you wanted to be flexible in expressing the requirement in the XML rather than expressing it out of band, then I would go back to the testing method and coercing "language" to be how to interpret the testing method.  I might tell recipients:

   <cac:ItemInstance>
     <cac:AdditionalItemProperty>
       <cbc:Name>Title</cbc:Name>
       <cbc:NameCode>TITLE_CODE</cbc:NameCode>
       <cbc:TestingMethod lang="listID">SellerTitleCodeList</cbc:TestingMethod>
     </cac:AdditionalItemProperty>
   </cac:ItemInstance>

This would tell the recipient that the testing method is a code list identified by the value of the element.  You would then send out of band the genericode file with the given identifier.  Actually, I suppose you could just point to your own web site using the approach implied by your original example:

   <cac:ItemInstance>
     <cac:AdditionalItemProperty>
       <cbc:Name>Title</cbc:Name>
       <cbc:NameCode>TITLE_CODE</cbc:NameCode>
       <cbc:TestingMethod lang="listURI"
   >http://my.company.com/catalogues/gc/title-code-list.gc</cbc:TestingMethod>
     </cac:AdditionalItemProperty>
   </cac:ItemInstance>

Then you don't have to send it out of band, you are indicating where the buyer can fetch the file.

But imposing the buyer to interpret the genericode file might be asking too much.  If you created an XSLT from a CVA file that expressed the constraints, then you could use something like:

   <cac:ItemInstance>
     <cac:AdditionalItemProperty>
       <cbc:Name>Title</cbc:Name>
       <cbc:NameCode>TITLE_CODE</cbc:NameCode>
       <cbc:TestingMethod lang="listXSLT"
   >http://my.company.com/catalogues/gc/title-code-list.xsl</cbc:TestingMethod>
     </cac:AdditionalItemProperty>
   </cac:ItemInstance>

... and then they fetch just a stylesheet and run their instance against the stylesheet.  That would be the least amount of work on their part since it is all canned up in the XSLT.  They don't have to compile the XSLT stylesheet from the CVA content.

>Any thoughts you had on this would be appreciated.

Lots of options to consider.

>I think if the ItemProperty is used the validation when ordering the
>item might have to vary based on the structure of the specific ItemProperty.

Right ... but if the language attribute of the test method value is used to describe what to do with the test method value, recipients would know what to do.

I don't think I'm stretching the interpretation of the <cbc:TestMethod> languageID attribute ... but I'll let a committee member slap my wrist if this is inappropriate.

I hope this is helpful.

. . . . . . . . Ken

>John
>
>-----Original Message-----
>From: G. Ken Holman [mailto:g.ken.holman@gmail.com] On Behalf Of G. Ken
>Holman
>Sent: Thursday, February 18, 2016 9:28 PM
>To: John Grekso; ubl-dev@lists.oasis-open.org
>Subject: Re: [ubl-dev] Question regarding item specification in
>Catalogue
>
>There are two places where one specifies properties for an
>item:  those that are properties of all examples of the item, and those
>that are specific to a given instance of the item.
>
>I would think that the name used to embroider a shirt would be an
>example of something specific to a given instance of the item:
>
>Catalogue
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_Catalogue.Details
>/ cac:CatalogueLine
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_CatalogueLine.Details
>/ cac:Item
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_Item.Details
>/ cac:ItemInstance
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_ItemInstance.Details
>/ cac:AdditionaItemProperty
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#t-CommonLibrary-1087
>
>And I would think the generic properties would go here:
>
>Catalogue
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_Catalogue.Details
>/ cac:CatalogueLine
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_CatalogueLine.Details
>/ cac:Item
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#Table_Item.Details
>/ cac:AdditionaItemProperty
>http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDo
>cuments-2.1.html#t-CommonLibrary-1056
>
>CAVEAT:  I'm an angle-bracket guy and not a business analyst but I try
>to answer questions like these in order to learn more about the
>business semantics.  If anyone on the list would like to question what
>I've suggested, please speak up!  I'm only speaking for myself in these
>kinds of answers.
>
>I hope this helps.
>
>. . . . . . Ken
>
>At 2016-02-19 02:47 +0000, John Grekso wrote:
> >Hi,
> >
> >I've looked around and haven't been able to find any guidance or
> >examples so I'm hoping someone might be able to help.
> >
> >We are currently looking at using the UBL Catalogue and for so far I
> >have been able to represent the scenarios we currently have.  There
> >is one scenario that I am having trouble representing.  We have
> >products that require additional information in order to be
> >purchased.  For example, a shirt might have embroidery and require
> >the name of the person to be specified.  In looking through the
> >components of the Item element though I am not seeing how this could be represented.
> >
> >Any help or guidance on where I could look or how this might be
> >represented would be much appreciated.
> >
> >Thanks,
> >John


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/u/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


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