Re: [ubl-ttsc] Charter

[Chin Chee-Kai <cheekai@softml.net>]

Gunther,

Thanks for sharing your ideas about development difficulties and
recommendations of such to NDR/LC to reflect an easier way of
schema representation.  You reflected on 3 issues, namely:

- Local vs global, that venetian blind way is more preferred
  due to lesser performance issues with end-user systems
- Dictionary names that need synchronizations and computations
  that are complicated.
- Type generation for Java classes, what are we going to do
  when all elements/types are global? 


I guess the points I was trying to make are:

- For local vs global, from TTSC point of view, if we are
  saying that the XSD schemas have performance issues
  using some totally valid ways of writing schemas as opposed 
  to your preferred venetian blind method which is another 
  totally valid way of writing schemas,  and for TTSC to 
  recommend one and not the other based purely on that, 
  then I think it seems to suggest a performance issue with
  the schema representation  technology itself as a whole, 
  and not so much a UBL issue any more.  

  Your point about not alienating developers trying to use 
  UBL and find that they have performance issues is well
  taken.  We certainly don't want to do things that end up
  making users buy bigger machines or take longer time than
  necessary.  But then again, globally types and elements 
  are equally valid ways to write in schemas than locally typed 
  schemas;  it will be still vanilla  schema processing that 
  end-users are computing, just that they are operating on 
  UBL schemas instead of other schemas.   

  And if UBL were  to choose local instead of global (or 
  the other way around) based on PURELY performance 
  considerations, I'm not sure what kind of message it'll 
  send to other groups and committees.

- I was explaining that when "complicated" is used to describe
  computations and formulas, I thought it would be more balanced
  if you could suggest also a way to quantify what is "complicated".
  Different programmers and developers around the world have 
  various levels of expertise, and what is complicated to one
  may seem so straightforward to another.  So to avoid being
  biased or seen as biased, you could provide some yardstick
  measure so others can be convinced of it being complicated.

- As for type generation for Java classes, I'm not very sure
  where the problem lies with global elements and types.
  The "global"ness of elements and types are only during the
  invokation of UBL processors, or UBL tools that process
  UBL schemas.  Once that conversion/operation is performed,
  the names in Java classes obey Java VM's type and variable
  name spaces.  One could actually do a lot of magic during
  the course of transforming from UBL schemas to Java class
  space.  

  For instance, attribute names are "flattened" out into 
  their immediate parent's level through in my trial implementation 
  of Java classes to ease GUI display and value retrievals. 
  The globalness of UBL attributes didn't affect the way they
  are being "localised" into their respective parent containers
  during the conversion.  How UBL defines types and elements
  need not exert undue influence on the converted destination
  forms since the tools has a fair amount of ability to 
  mangle things into the right shape.

  Or if you see other difficulties, then perhaps I'm not
  getting it fully and you could explain with examples.




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Thu, 22 May 2003, Stuhec, Gunther wrote:

>>Tools and Techniques SC (TTSC)
>>
>>
>>Charter
>>To evaluate and recommend to the TC the tools and techniques 
>>to be used in the development, quality assurance, documentation,
>>maintenance, and revision of the UBL XML data formats, and write
>>and maintain guidelines reflecting these recommendations.
>>
>>Members
>>Chair: Arofan Gregory (CommerceOne)
>>
>>Doug Bunting (Sun Microsystems)
>>Bill Burcham (Sterling Commerce)
>>Dave Carlson (Ontogenics Corp.)
>>Eduardo Gutentag (Sun Microsystems)
>>Eve Maler (Sun Microsystems)
>>Dale McKay (Northrop Grumman)
>>Kelly Schwarskhoff (Commerce One)
>>Gunther Stuhec (SAP AG)
>>