[wg11] Part 28 teleconferences

[David Price]

All,

It occurs to me that this approach to understanding requirements isn't
helping as much as I'd hoped. Perhaps we could agree the set of features of
interest for something like the following aspects of P28 use and then let
each community describe how important that feature is to them?

1) The configuration language itself

2) Part 28 E2 itself (or Part 2x and Part 28 E2)

3) the resulting XSDs

4) the environment within which the XSD is used

5) the background/expectations on the developers using the XSD might have

Does this approach make sense to anyone else? If not, anyone got an idea
that's better than each of restating what we think the other community's
requirements might be?

Cheers,
David

> -----Original Message-----
> From: wg11-bounces at steptools.com [mailto:wg11-bounces at steptools.com] On
> Behalf Of David Price
> Sent: 14 July 2004 23:49
> To: wg11 at steptools.com
> Cc: xmlsc4 at nist.gov
> Subject: RE: [wg11] Part 28 teleconferences
> 
> All,
> 
> I'm a bit confused. If there's no user scenario/requirement where the
> runtime requires access to the EXPRESS/Part 28 parser, then why is the
> Part
> 28 Base XSD and Configuration XSD required when validating the XML
> document
> against the XSDs?
> 
> I do want to continue to try and explain about the communities that want a
> simple XSD and that do not want to learn EXPRESS. The complexity of the
> directives required by the XSD generator to not have to be simple. Only
> the
> resulting XSD has to be simple. So, removing all the configuration
> capability is not necessarily the answer if it turns out that AIM-based
> and
> ARM-based XSDs have different user communities with different needs.
> 
> Cheers,
> David
> 
> > -----Original Message-----
> > From: wg11-bounces at steptools.com [mailto:wg11-bounces at steptools.com] On
> > Behalf Of Ed Barkmeyer
> > Sent: 14 July 2004 21:47
> > To: wg11 at steptools.com
> > Cc: xmlsc4 at nist.gov
> > Subject: Re: [wg11] Part 28 teleconferences
> >
> > David Price wrote:
> >
> > >>1)  a simple non-validating schema with a simple data mapping,
> > >
> > > An XML schema driven from EXPRESSS designed for a non-STEP- and
> > > non-EXPRESS-literate community of users who do not have access to any
> > > EXPRESS or Part 28 tool.
> >
> > I'm not sure that the literacy of the modeling literacy of the community
> > is what is at issue here.
> >
> > I would have said: An XML schema derived from the EXPRESS model by
> > fairly simple rules with no options, where necessary eliminating
> > restrictions and features that make the XML schema difficult for people
> > to read and tools to use.
> >
> > >>2)  a schema that provides type checking, and
> > >
> > > An XML schema designed for XML use by the STEP community in a more-or-
> > less
> > > traditional STEP implementation environment with access to
> EXPRESS/Part
> > 28
> > > tools.
> >
> > This is exactly the opposite of what is wanted, as Tom indicated.  The
> > idea here is to produce a schema that allows XML-only tools to validate
> > the data, by incorporating in the XML schema as many of the constraints
> > and implications of the EXPRESS schema as possible.
> >
> > If the XML is processed in an EXPRESS-aware environment, then the
> > EXPRESS schema is the basis for validation, and the XML schema can be
> > much simpler, as in case (1).
> >
> > >>3)  a configurable schema.
> > >
> > > A pre-existing XML schema is defined somewhere and Part 28 is used to
> > > specify the relationship between it and a STEP EXPRESS schema covering
> > the
> > > same scope.
> >
> > Yes.  This is what I understood, and I think this matches Günter's (2b).
> >
> > > The pre-existing schema creator did not take the STEP EXPRESS
> > > schema structures into account when creating the XML Schema.
> >
> > This part is either totally wrong or totally irrelevant.  What Martin
> > and Günter both have in mind is that the AP developers (or some
> > consortium of AP users) will specify a normative XML schema that covers
> > exactly the same underlying data model as does the normative EXPRESS
> > schema.  So they are fully aware of the normative EXPRESS schema.
> >
> > The purpose of the configuration language is to define the mapping
> > between the data elements modeled by the normative EXPRESS schema and
> > the data elements specified by the XML schema.  The expectation should
> > be that there is a one-to-one onto mapping for all the conceptual data
> > elements in the EXPRESS ARM, but they may be somewhat reorganized in the
> > XML.  In effect, the configuration language is the language of a
> > "mapping table" between the EXPRESS schema and the XML schema.
> >
> > This mapping can be phrased "forward" -- from the EXPRESS schema
> > elements to the XML schema elements -- or "backward", from the XML
> > schema elements to the EXPRESS schema elements.  If we state the mapping
> > forward, it allows the XML schema to be generated from the EXPRESS
> > schema, and tells a processor how to reorganize the EXPRESS-modelled
> > data into the XML.  If we state the mapping "backward", it tells the
> > processor how to generate the Part 21 file from the XML document.
> >
> > The current configuration language approach is "forward" and "by
> > exception".  That is, it assumes the default mapping (one of (1) or (2)
> > above) and specifies only the mapping for elements that do not match the
> > default mapping.  I would suggest that we continue with this approach to
> > (3) in order to save time.
> >
> > I agree with Günter that, for this purpose, the current configuration
> > language is "too much and not enough".  It isn't quite powerful enough
> > to cover all the organization and naming transforms that are wanted, and
> > it includes directives that have nothing to do with the target XML
> schema.
> >
> > I think Günter is also right that (1) and (2) are orthogonal to (3).
> > The amount of EXPRESS constraint that is captured in the AP-specific XML
> > schema will be what it is, presumably somewhere between (1) and (2), and
> > the AP developers/users only need to say in the configuration language
> > which kinds of EXPRESS constraints the XML schema should capture.
> >
> > -Ed
> >
> > --
> > 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."
> >
> > _______________________________________________
> > wg11 mailing list
> > wg11 at steptools.com
> > http://lists.steptools.com/mailman/listinfo/wg11
> 
> 
> _______________________________________________
> wg11 mailing list
> wg11 at steptools.com
> http://lists.steptools.com/mailman/listinfo/wg11