[wg11] Part 28 Issue : Do we need all this configurability?

[David Price]

Ed,

Thanks for the reply. It's easy to see that there are competing objectives
wrt the purpose of Part 28 E2. These are difficult issues. I think I'm
beginning to come to the conclusion that we need to separate what SC4
standardizes from what EXPRESS tools support. 

- The STEP community needs relatively straightforward XML Schema
representations of EXPRESS schemas for data exchange. We need a single
approach for that.

- There are other uses of EXPRESS and toolkits might want to support more
complicated mappings into XML Schema for other purposes.

I'm beginning to think something like the following:

1 - for AIM-based exchange use P21 or P28 Edition 1 ( or the new Binary
representation next year!)

2 - for modular ARM-based exchange use a single P28 Edition 2 mapping to XML
Schema

3 - for any other use, P28 Edition 3 can define the configurations (The
Edition 3 is *not* a mistake, it's what's there now just defered)

Our concern is that the industry projects need XML Schema today and cannot
wait for SC4 to get configuring XSDs right. We should get something workable
out for XML Schema users and defer the rest of P28. By the way, it's
possible that the Part 25->UML->OMG QVT or an EXPRESS->OWL mapping for data
exchange can satisfy some of these requirements.

Hope this is helpful,
David

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark at nist.gov]
> Sent: 21 May 2004 17:18
> To: David Price
> Cc: SC4 WG11; Multiple recipients of list
> Subject: Re: [wg11] Part 28 Issue : Do we need all this configurability?
> 
> David Price wrote:
> 
> > Is there support for removing or vastly reducing and simplifying the ISO
> > standard EXPRESS to XML Schema configuration capability in Part 28? For
> > example, could we agree on an EXPRESS to XML schema mapping for each
> > usage scenario (e.g. data exchange vs. SOAP) and standardize those
> instead?
> 
> For what it's worth, David, it is the NIST position that most of the
> elaborate configuration language is unnecessary and hinders
> interoperability.  Whether the U.S. ballot comments will reflect such a
> position is "quite another thing entirely", in that two other U.S.
> organizations have crafted most of the options that NIST considers least
> useful.
> 
> What we are facing, however, is three problems:
> - The default rendering of an EXPRESS AIM schema into an XML schema will
> not produce an XML schema intended for use by human engineers who are
> not STEP experts.  It will not result in increased use of STEP models in
> ebXML and other business exchanges, because it will be ugly,
> counterintuitive, and difficult for non-STEP-expert analysts and
> programmers to work with.  And if it can only be used by STEP experts,
> why should we not just continue using Part 21 for all STEP exchanges?
> - When an XML schema is developed from STEP models with the express
> intent of reaching this business data exchange community, "it would be
> nice if" there were a standard mapping language in which the
> relationship between the XML schema and the normative EXPRESS schema
> could be formally described.  Several participants see this as the
> primary purpose of the configuration language.
> - Several XML schemas based on STEP models have been constructed and are
> in pilot or production use in certain communities.  The toolsmiths and
> user communities who have invested in this effort would like the
> standard to support 90+% of what they have in "product".
> Unsurprisingly, there is nearly no consistency in their various
> approaches to mapping EXPRESS reference models into useful XML schemas.
>   Which of them do we choose as the only conforming one?
> 
> In my personal view, these three problems demand three different
> solutions:
> - Use more intuitive EXPRESS ARM schemas for XML exchanges.  The mapping
> tables will tell you how to construct the AIM equivalent, for those of
> you who still believe that AIMs are good for something.  The problem is
> that only a few APs have useful, normative and complete ARM schemas.
> - Include a formal EXPRESS-to-XML-schema mapping language in Part 28 (or
> some spinoff) that allows complex transformations.  Require its use as a
> documentary element of any hand-crafted XML schema that becomes part of
> an SC4 standard.
> - In Part 28, pick one general intuitive approach to mapping EXPRESS
> schemas to XML schemas, even if it is somewhat complicated (both EXPRESS
> and XML schema are).  This will probably render 10-20% of every "in
> product" implementation invalid and send people who made certain bizarre
> choices back to the drawing board.  Standards not drawn from active
> practice have a way of doing that.
> 
> The problem with my approach, of course, is that Part 28 itself can only
> really address the last of these (and perhaps half of the second).  But
> without the other two, it will be the solution to no real problem, other
> than allowing us to say STEP and XML in the same sentence.
> 
> -Ed
> 
> P.S. Sometimes doing the wrong thing well actually begets a useful
> solution to the problem, albeit indirectly.  Thus far in Part 28, it has
> not proved to be the case, but now we come to the first ballot.
> 
> --
> Edward J. Barkmeyer                        Email: edbark at nist.gov
> National Institute of Standards & Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
> Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694
> 
> "The opinions expressed above do not reflect consensus of NIST,
>   and have not been reviewed by any Government authority."