RE: [ubl-lcsc] An impact on stylesheets by global names vs. localnames decision

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

But what if you needed to process Party structures Ken?  That is, what if
you had code (template), similar to your Address processing, that you wanted
to act on all Parties?  You'd be stuck wouldn't you (since the tags in each
kind of Party differ)?

The ramifications Ken cites, are a result more of the last minute change to
"long" tag names than of the decision to use globally-scoped element
declarations.  What was being enforced by globally-scoped element
declarations was that whenever one saw the tag "CityName", one was
guaranteed that it had precisely the same structure.  The vocabulary could
still have many content models containing that tag (CityName).  Long tag
names (tag names that include the Object Class) foreclose on the possibility
of such reuse.

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Sunday, January 19, 2003 10:37 PM
To: UBL LCSC
Subject: [ubl-lcsc] An impact on stylesheets by global names vs. local names
decision


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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>