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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ttsc message

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


Subject: Re: [ubl-ttsc] No call


Hi,

Here are my notes from the last meeting.  Sorry to have taken so long on 
these.
I didn't note that there were any specific action items from the 
meeting, but
in looking at the schedule Tim sent out this week to lcsc (also attached),
it shows ttsc doing tools configuration for the past couple of weeks,
ending Monday the 16th (11 days from now) with a set of alpha quality
0p80 schemas for review by the LC modeling and QA teams.  Is this realistic?
I do recall Gunther saying that the schemas could be hand-crafter for now
because the new ndr rules are not yet reflected in the tools, so perhaps
that is the plan of record and is not a problem to get done by the 16th,
but I just thought I'd get people thinking in the direction of this 
schedule,
since I'm not sure how much overlap we have in membership/attendance between
the LC meetings, the NDR meeting, and this team.  Since there's no TTSC
meeting this week, what about using a few minutes on this Friday's LC
call to give a TTSC update (assuming Tim agrees, of course, but I can't
imagine he wouldn't)?

Thanks,

-Anne


Lisa-Aeon wrote:

>TTSC members, Gunther called me today to have me email out for his apologies
>that he can not have tomorrows TTSC call.  He is on vacation for two weeks.
>Maybe we can have a call without him next week and at least discuss the
>issue and action items from the last call.  Let me know if you are
>interested.
>
>Lisa
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++
>Lisa Seaburg
>AEON Consulting
>Website: http://www.aeon-llc.com
>Email:  lseaburg@aeon-llc.com
>Alternative Email: xcblgeek@yahoo.com
>Phone: 662-562-7676
>Cellphone: 662-501-7676
>
>"If you obey all the rules, you miss all the fun."
>                       -Katharine Hepburn
>++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.474 / Virus Database: 272 - Release Date: 4/18/2003
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-ttsc/members/leave_workgroup.php
>

The UBL Tools and Techniques Subcommittee met on Thursday 22 May 2003.


U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229


Attendees:
==========

Chee-Kai Chin
Anne Hendry
Kris Ketels
Lisa Seaburg
Gunther Stuhec
Paul Thorpe


Agenda:
=======
1.) Sorting and prioritizing of all requirements
2.) Look for volunteers of the high-prioritized requirement
3.) Every volunteer should proof the following:
    - which tools are useful for our requirements? 
    - which features of the tools are useful for our requirements? 
    - which steps can be done manually or automatically? 
    - which features must be added for our requirements? 
    - which developments must we do (tools, functions)
      that we can use UBL XML in this tools? 
    - which NDR rules must be changed so we can use
      UBL XML more efficiently in this tools? 
4.) Defining a time schedule for the described steps above
    (requirements and testing)
5.) Other business
6.) Adjourn
										
									
0.) Team 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 the UBL XML data formats, and write and maintain guidelines
    reflecting these recommendations."

    Chee-Kai / Kris:
       Is tools only for internal methodology, or also for external adopters?

    Gunther:
       Questions we should ask of tool set:
       a) How we can use ndrsc rules with different tools and apps?
          - apps like xml native databases, java parsers, sax/dom parsers,
          - like interfaces for svg, user interfaces
          - which tools are necessary for our requirements,
            which for ndr definitions
       b) Which tools are useful for modeling libraries, which tools are good
          for defining interfaces, which tools for generating instances from
          xml schemas, etc?
       c) Are the ndr definitions useful to define current tool set?
	  Sometimes seemed from London that the schemas are not defined
          efficiently enough for requirements of tools.

       Maybe we can the change charter a bit based on requirements from
       ndrsc and lcsc.  Using that I can see 3 parts:
       1) modeling part from lcsc mainly, and storing of ccs in databases;
          expression of xmi; lcsc focusing on modeling part so we need to
          look at how to show ccs efficiently, for example; how user can
          do adminstration to change these
       2) xml native datgabases; xml schema generators like xmlspy
       3) generation of interface itself; generating Java classes, C++
          classes efficiently

      The key issue of ttsc is to look at how to use rules to do implementation.

   Paul: Is it the charter of our group to come up with guidelines on how to
      create these artifacts, or to recommend tools on the market that will
      enable us to create interfaces, etc.?

   Gunther: The second - recommend tools, not so much guidelines, on how we can
      use the xml schemas with differnt tools (see requiremetns #14 - #17 below)
      After we check these things we can see how we might define a tool for
      modeling some business documents and for changing xml documents.

   Paul: We should be able to determine how a product should behave, without
      specifying the exact product, though - just state requirements/features
      that tools need to support to do what we want to do.

   Chee-Kai: Yes, TTSC should not itself endorse certain products - this might
      get vendors involved in a way that is not actually beneficial to the TC.

   Gunther: We need to support xml schemas, which come from ndrsc rules.
      We might need to do hand-crating of schemas for a first step, though,
      then see if xml schemas are useful for modeling.  Because if you look
      to lcsc library, you see that this libaray does not use the new ndrsc rules;
      there are also further conflicts which impact the schemas in a large way,
      that make it difficult to put in the perl scirpt.  So, that's why I say
      we may need hand-crafted schemas based on ndr rules for the initial work.

   Chee-Kai: Are you saying that ndr schema rules are too difficult to
      implement now, so we should hand-craft them for now?

   Gunther: Since we have not tested any of the ndr stuff - storing of schemas
      into databases - lcsc should be concentrating on spreadsheets now and
      defining libraries using spreadsheets only.  It makes no sense for lcsc
      to look at the schemas now becuase that's not yet useful.
      We have to look at how we define xml schemas based on the new rules of
      ndrsc and see how we can use these with differnt tools and interfaces,
      to help us see at an early stage if the tools are useful.
      If we find issues with new rules - that it isn't possible to use them
      efficiently - we should report those to ndrsc.  We will do a proof of
      concept on ndrsc rules.

   Kris: What about checking ubl against existing tools that are out there
      and generate feedback to ndr based on that?

   Gunther: Yes, we can check against exisitng tools and say what's difficult
      with current schemas and also say what extensions are need to the tools
      to do our work more efficiently (generate schemas).  But it is necessary
      to find problems out now.  In our work we found it was better to take
      the venetian blind approach - based on object oriented modeling approach
      and other normal java approaches.

   Kris: An example we encoutered was that we initially developed our xml
      solution and had our customers come back to say our messages were
      way too long.

   Gunther: Yes, we need to look at how to implement schemas more efficitenly
      and make sure the ndr rules are helpful, that they don't require too
      many changes.

   Chee-Kai: When final schemas are published and developers are using them,
      they will use generic tools.  The internal tools are probobaly only
      executed once.  The tools are meant to support ndr for designing and
      lcsc for modeling/semantics.  We should be helping them change this
      into normative xml schemas.  Issue Kris brings up falls between naming
      and lcsc, but the tools should implement what ndrsc and lcsc decide.

   Gunther: Yes, the primary thing is to implement ndr rules thorugh the tools,
      to do generation from xsl into xml schema, graphical modeling tools, etc.
      But, if we can see it's very hard to define apps - that we need a lot of
      exceptions to do the work, or have a lot of conflicts between the
      structures - then we should look at how we can do this better by
      redefining the schema.  Many developers are ignoring complicated schemas
      because it is too hard to parse, generate, etc.  One of the key issues
      of future generations of business languages is that you can use it for
      developing apps efficiently.  So we should look at how to genearate apps
      efficitently using xml schemas.

   Chee-Kai: If implementations create problems, yes, that needs to be surfaced,
      but if you are talking about different ways to write schemas (because xml
      schema allows implementations in several different ways), this doesn't
      seem to me to be a UBL issue that is debated upon by NDR.  If we identify
      a particular way of writing schema to be a problem, yes, we should pass
      that on to ndr, but it's not our issue to rewrite the schema, because
      this will be a problem for all people writing schemas, not just UBL.
				|
   Gunther: I'm not looking at the options of designing schemas, just to raise
      issue that current definitions of ndrsc will be an implementation problem
      (eg. local vs. global, venetian blind, etc).  Otherwise implementers of
      Ubl schemas into their apps will see it's too complicated and they'll
      ignore ubl which will be a problem.  Better if we do this as a group.

   Chee-Kai: yes, we don't want to alienate people, but if xml schema is a
      recommendation from W3C and we are making statement that this is too
      complicated, then it suggests that in general all schemas written this
      way would have a problem.

   Gunther: Next week we'll discuss modifying the charter.

   Gunther: For now, look at tools, and then if there are problems in
      implemenation, we'll raise these to ndrsc.  Otherwise, if we see tools are
      not useful beacuse features are missing, then we write recommendations on
      this for further features for ubl to use the tools more effectively.

   Gunther: For now we can write quick-and-dirty for testing/poc,
      but not develop complicated apps becasue the time is too short.

   Chee-Kai: Is there a way to quantify this complication you talk about?
      If this is proposed to the public, there will be questions to say
      what is complicated.  To some maybe complicated, but maybe not to others.

   Gunther: Normally in future people will be definiting libraries by using
      ccts stuff - not xml, ccts.  Defining dictionay entry names.  These are
      separeted by dashes/points; these must be always unique.  But now,
      it's interesting - you can write tools to generate tag names from
      dictoinary entry names automatically.  Maybe if we can see - oh,
      that is vey complicated because need to do double-checking, validation
      - then always I would like to say 'change tag names from global delcared
      tag names'.  It is easy to see how we can generate tag names from d.e.n.
      That is one issue i'd like ot reaise up; another is that normally you use
      types to genrate java classes to use object inside of java environment.
      But now you have globally declared elements.

Schedule for Monteal:
   Weekly meetings, Thursdays, 1-1/2 hours, 7:30 am PDT.


TTSC Requirements (from ttsc and ndrsc):
==================

1.)  non-proprietary storage format
2.)  availability on multiple platforms
3.)  configurable to syntax rules
4.)  configurable to customization rules
5.)  provides version control
6.)  requires no manual editing
7.)  supports XMI change format
8.)  is an integrated tool set
9.)  provides collabortive central source repository
10.) enforces a controlled vocabulary
11.) provides a single data/source repository
12.) low (no) cost
13.) Modelling systems 
     a.) based on XML Schemas (like XML Spy) 
     b.) based on UML Class Diagrams or graphical representation of the core components (may be based on SVG) 
14.) Storage systems 
     a.) native XML Databases 
     b.) flat file 
     c.) SQL Databases
15.) Transformation systems - Tools for writing efficient XSLT scripts for transforming into HTML or another kind XML based business language
16.) Intefaces generation systems 
     a.) Automatic generation of Java-Classes 
     b.) Automatic generation of C++-Classes 
     c.) Automatic generation of Perl-Classes 
     d.) Tools for generating user interfaces automatically, which are based on UBL XML Schemas 
17.) Schema generation systems - Generation of UBL based XML Schemas from and to
     a.) UML tools, 
     b.) Excel-spreadsheet, 
     c.) Java, 
     d.) C++, 
     e.) Perl-Classes 





pdf00004.pdf



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