[ubl-lcsc] An impact on stylesheets by global names vs. local namesdecision

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Just a quick comment on stylesheets that may be reflected in all general 
processing of UBL instances.

In 0p65 I was able to share a lot of stylesheet code, for example, the 
processing of "Name" and "Address" was the same for all parties:

   <SellerParty>
     <Name>
       ...
     <Address>
       ...
   <ConsigneeParty>
     <Name>
       ...
     <Address>
       ...
   <BuyerParty>
     <Name>
       ...
     <Address>
       ...

Once I set the context using XPath expressions to get to the party, I was 
able to then use common code for all name address processing in that context.

In the draft 0p70 version I have:

    <OrderBuyerParty>
       <BuyerPartyID>R300</BuyerPartyID>
       <BuyerPartyPartyName>
          <PartyNameName>IDES Retail INC US</PartyNameName>
       </BuyerPartyPartyName>
       <BuyerPartyAddress>
          <AddressID/>
          <AddressStreet>West Chester Pike</AddressStreet>
          <AddressCityName>Parsippany</AddressCityName>
          <AddressCountrySub-EntityCode>NY</AddressCountrySub-EntityCode>
          <AddressCountry>
             <CountryCode>US</CountryCode>
          </AddressCountry>
       </BuyerPartyAddress>
    </OrderBuyerParty>
    <OrderSellerParty>
       <SellerPartyID>R3002</SellerPartyID>
       <SellerPartyPartyName>
          <PartyNameName>Meyer Hardware Inc.</PartyNameName>
       </SellerPartyPartyName>
       <SellerPartyAddress>
          <AddressID/>
          <AddressStreet>South Hollow Road</AddressStreet>
          <AddressCityName>London</AddressCityName>
          <AddressCountry>
             <CountryCode>UK</CountryCode>
          </AddressCountry>
       </SellerPartyAddress>
    </OrderSellerParty>

Note how even though PartyNameName and AddressStreet are the same, the 
intervening <???PartyPartyName> and <???PartyAddress> constructs make the 
hierarchies different.  I'm pushing my common functionality "down" one 
level ... I can do the same address processing, but no longer the name 
processing because <Name> and <Address> have become globally unique.

I have accommodated it, but I wanted to bring it to your attention because 
the choice to abandon context and utilize global names has reduced an 
application's ability to share application code.  What I experienced in 
stylesheets also applies to programs.

I confess not to have been party to the earlier discussions deciding global 
vs. local naming, so I am unaware of the decision criteria and won't judge 
the appropriateness or inappropriateness of the decision.  This post is 
just recording an observation of the outcome of that decision and the 
impact on contextual processing of elements with like types.

.................... Ken

--
Upcoming hands-on in-depth   Europe:         February 17-21, 2003
XSLT/XPath and/or XSL-FO     North America:      June 16-20, 2003

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)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 0-13-140374-5                              Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1              Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc