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] | [List Home]


Subject: Is Local/Global a Type-reuse issue?


At 2003-06-24 23:52 +0800, Chin Chee Kai wrote:
>This isn't so much of a global/local issue than a type-reuse issue.

Ahhhh ... my confusion then ... I thought the global/local issues *was 
entirely* a type-reuse issue.

>The type-reuse mechanism (what you described as "single type
>for all parties") was carried over from the 0.80 spreadsheets'
>model change to reuse more types that are literally exact
>copies with different names when they were in 0.70 (as you
>pointed out).  I think there was no position change from
>the London meeting on encouraging type-reuse.

Ummmmm ... then I apologize for being so very confused.  Because if I look 
at the XPath addresses in 0.70, I see the following:

   /po:Order/cat:BuyerParty/cat:ID
   /po:Order/cat:BuyerParty/cat:PartyName/cat:Name
   /po:Order/cat:BuyerParty/cat:Address/cat:ID

After the London meeting I was anticipating seeing:

   /po:Order/cat:BuyerParty/cat:ID
   /po:Order/cat:BuyerParty/cat:BuyerPartyPartyName/cat:BuyerPartyName
   /po:Order/cat:BuyerParty/cat:BuyerPartyAddress/cat:ID

Type reuse of cat:Address would not allow the element members of that type 
to have different labels under different parent elements.

Don't get me wrong ... I *want* what I had in 0.70 where all of the address 
components of all of the parties had the same labels because they were of 
the same type:  Address.

What I thought was happening with the global/local discussion is that 
type-based programmer approaches to database-oriented applications needed 
individual types such as BuyerPartyAddress because the BuyerParty type was 
necessarily different than the SellerParty type, thus producing different 
element labels used in the types, thus producing different element labels 
under each kind of party in the instance.

The reason I wanted label-based processing (all parties share a common 
Address type, thus the labels used in the address are common to all 
parties) is to promote stylesheet fragmentation.  XSLT 1.0 does not do 
type-based processing.  While XSLT 2.0 *does* do type-based processing, it 
isn't here yet, thus causing me to go through hoops to try and implement 
type-based processing in a label-based stylesheet language.

Can I, then, rely on what I see in 0.80 Draft 3 that type-reuse, which ends 
up becoming label-reuse because the type described the labels for my 
element types, is going to be in the final 0.80?  I would be relieved to 
hear so.

Thanks for your patience with my misunderstanding!  Please let me know if 
anything I've said above is confusing ... I've tried to be as clear as 
possible.

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

--
Upcoming hands-on courses: XSLT/XPath North America: Aug 12, 2003
-                          XSL-FO     North America: Aug  4, 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-11-X              Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:    http://XMLGuild.info
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc



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