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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: [ubl-lcsc] Truncation Rules

Title: Truncation Rules

Hello all,

I would like to say something to the truncation rules. Since we've using global declared rules, we will get very long and redundant tag names like:

"CatalogueItemIdentificationItemMeasurement" (Object Class = "CatalogueItemIdentification" and "Item")
"HandlingUnitDespatchLineDespatchedQuantity" (Object Class = "HandlingUnitDespatchLine")
"HandlingUnitDespatchLineLineID" (Object Class = "HandlingUnitDespatchLine")
"HandlingUnitDespatchLineOrderLineID" (Object Class = "HandlingUnitDespatchLine")
"PaymentID" (Object Class = "Payment")
"PaymentTermsText" (Object Class = "PaymentTerms")
"PaymentTermsDetails" (Object Class = "PaymentTerms")
"PaymentTermsID" (Object Class = "PaymentTerms")
"HandlingUnitReceiptLineID" (Object Class = "HandlingUnitReceiptLine")

I guess, this global declared elements will have one advantage. You can use this declared tag name and the type, which the global declared element is based, only. But we will coming into trouble, if we well defining any truncation rules for global declared elements. What would you like to truncate from the examples above?

All my found rules will be not waterproofed or need some further difficult exception rules. Additionally, the automatic processing for extracting tag names will be not possible any more.

For example:

1.) If you would like to delete all Object Classes from each tag name of global declared element, like:
        HandlingUnitReceiptLineID ==> ID
        PaymentID ==> ID
Than, the global declared element will be not unique any more. There is no modification (restriction/extension) possible any more. Because, If you do any modification with the global declared element "ID", it will be influenced all "IDs" within every aggregates.

2.) The deletion of "Text" or "Details" is not possible any more, because it expressing the different kind of representation. Like:

        PaymentTermsText ==> PaymentTerms
        PaymentTermsDetails ==> PaymentTerms
Both elements will come into conflict, if we using this rule.
For that, we need a further rule, like: All BBIEs as well as BCCs, which based on the Representation Term "text" must have a Property Term which is different as the Representation Term.

But UBL is not responsible for this rule. This rule impacts the ebXML CCTS completely. I guess, it is not an urgent reason, to define kind of rule within the ebXML CCTS.

3.) We can delete all same words. Like:
        CatalogueItemIdentificationItemMeasurement ==> CatalogueIdentificationMeasurement
        HandlingUnitDespatchLineLineID ==> HandlingUnitDespatchLineID
        HandlingUnitDespatchLineOrderLineID ==> HandlingUnitDespatchLineOrderID
This truncation rule have three disadvantages: a.) It shorten the tag names not very much, b.) the semantic meaning of the truncated tag names will be different as the origin semantic meaning and the c.) the tag names itself will be not really unique.

4.) We using for the tag names the first 2 or 3 letters of every term only. Like:
        CatalogueItemIdentificationItemMeasurement  ==> CatIteIdeIteMea
        HandlingUnitDespatchLineLineID ==>HanUniDesLinLinID
        HandlingUnitDespatchLineOrderLineID ==> HanUniDesLinOrdLinID
This rule will missing our plan "human readability" completely. In addition, this abbreviations will be not unique. Better is, if we using UDEF or the UUID for the tagnames.

We can do a combination of all rules above. But I guess, if we will get by this way a waterproofed solution, than we need a lot of exception rules. That makes our UBL specification very difficult and not implementable. I guess, a lot of implementors will ignoring this specification, than.

I think, one of the best way is this way, which we're using for local defined elements. Like:

        <xsd:complexType name="AddressDetails" id="UBL000563">
                        <xsd:element name="ID" type="AddressID" id="UBL000564"/>
                        <xsd:element name="Postbox" type="AddressPostbox" id="UBL000565" minOccurs="0"/>
                        <xsd:element name="Building" type="AddressBuilding" id="UBL000566" minOccurs="0"/>
The types (complex types or simple types) itself are always unique. If you using this types within an aggregation with the the object class term, than you can delete this object class term from every subelement. This is a very clear and understandable rule and very efficient. Additionally we can use our truncation rules for "text" and "details" without any exception rules.

Furthermore all subelement will be unique within every aggregation. There is no redundancy, because aggregate give us the "Object Class Term" and the subelements includes the "Property Terms" as well as the "Representation Terms". If we concatenate this information together, than we will get the complete dictionary entry name again. We can express all dictionary names by XPath very efficiently.

Additionally, I know a couple of logical rules for truncating tag names. This rules allows always the complete readability and the uniqueness of the elements. But this rules can be used in my suggestion only. Otherwise, you need a lot of exception rules, too. And I said, all additional exception rules makes our NDR very uninteresting.

Someone said to me, that we can using both, my suggestion and global declared elements, very easily, if we're using this global declared elements in different namespaces. But this makes no sense. Because you will see the prefixes of namespaces in the instances. And the prefixes could be the object class terms (We've no rules for the definition of namespace prefixes, yet). Therefore, you will get the same length of tag names.

May there is one possibility to use my suggestion in combination with global declared elements. But I don't know this possibility yet.

Kind regards,


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

Powered by eList eXpress LLC