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


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



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