[wg11] Part 28 teleconferences

[Ed Barkmeyer]

David Price wrote:

> 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?

There are two answers to this:
1.  The simple XML schema (Heidi's option 1) is intended to be supported 
by EXPRESS-based validation.  (You don't need extensive XML validation 
if you are going to do EXPRESS-based validation.)  The simple XML schema 
is also easier for the "typical Vbasic programmer" (TVP) to use and the 
"XML-only modeler" = "modeler somewhat literate in XML Schema" to 
understand.  Neither of them needs to know much about the EXPRESS 
references, except that it is part of the magic incantation that 
precedes the data.  So option 1 serves 2 objectives:  EXPRESS-based 
validation and presentation to illiterate model readers.

2.  The Part 28 Base XML Schema is an accident of the design of the 
standard.  We factored all of the stuff that is invariant over all Part 
28-conforming schemas into a single XML schema and made that schema a 
normative resource.  We could have created 3 separate normative resource 
schemas, or simply required a conforming XML schema to contain all of 
those declarations, or at least the ones it uses, verbatim.  The three 
"separable base schemas" are:
- the configuration language schema
- the document structure schema
- the data types and elements that may be used in a derived XML schema
I would also observe that the last group is made much larger by the 
existence of the map directive.

[It wouldn't bother me to have separate resources and separate XML 
namespaces for each of the 3.  And it wouldn't bother me if we changed 
the standard to mandate the inclusion of the last group directly in the 
derived XML schema, but I don't think that is a better idea.  In 
general, interchange will be more reliable if people import data type 
sets rather than defining their own.]

> 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.

The main issues with the configuration capability are also twofold:

1) As currently described, the configuration capability allows any 
"preprocessor" to choose a configuration set that generates a derived 
XML schema its author/user likes, and generate data sets conforming to 
that schema.  The result is that there are thousands of different XML 
data organizations and representations that conform to a given normative 
EXPRESS schema and to Part 28, and any one you use is conforming, even 
if no one else agrees to use that one.

2) To make this "agreement to disagree" work, a conforming 
post-processor is required to accept *any* of those conforming 
organizations and interpret it properly.  In effect, the postprocessor 
must dynamically generate the XSLT transform to the form it uses as a 
reference for data interpretation and perhaps EXPRESS validation.  (In 
practice, a postprocessor will generate the transform once, and reuse it 
every time it sees the same configuration file, assuming the 
preprocessor is kind enough to provide a URN and change it when the 
version of the configuration file changes, but of course we don't 
mandate that, either.)

[I personally regard the configuration capability, as currently 
specified, as totally counterproductive.  The U.S., however, holds no 
such position.]

Note, please, that everyone who thought they wanted this capability, in 
order to make their favorite XML representation conformant, has realized 
the cost of reading other people's documents and (with one notable 
exception) changed their minds.

What has emerged instead, from at least STEPTools (AP238) and 
PDTEC/ProSTEP (AP214) is a requirement to be able to describe the 
transform from the normative EXPRESS model to a specific normative XML 
schema that was designed to support the EXPRESS (ARM?) schema.  For that 
case, what is required of preprocessors and postprocessors is to conform 
to the standard that defines that normative XML schema.  The 
configuration feature of Part 28 allows the normative XML specification, 
or some supporting specification, to define the EXPRESS->XML Schema 
transform in a standard language.  And that enables a "smart" 
post-processor, of the kind the current Part 28 requires, to process 
this "foreign" XML data organization against the normative EXPRESS 
schema, and perhaps convert the data sets to a Part 21 form or some form 
that supports SDAI access.

As I understand that approach, it would make the documents conforming to 
the "foreign" XML specification "conformant to Part 28 only by 
extension" or something like that.  But no one cares whether that 
*document* "conforms to Part 28"; what is important about that 
*document* is that it conforms to AP238 or to the OMG PLM or to some 
OASIS spec.  What Part 28 defines for that case is "conformance of the 
configuration file" and "conformance of the smart post-processor" -- the 
enablers for the advanced tooling that brings these "foreign XML 
schemas" into existing SC4-technology environments.

The main thrust of the U.S. position is that there must be one standard 
XML representation that corresponds to a normative EXPRESS schema, and 
it must be simple enough to be inexpensive to program for.  There may be 
two conforming XML schemas that describe that XML representation -- one 
simple description, and one utilizing additional XML schema features to 
improve "validation" capabilities.  But "validation capabilities" and 
"configuration capabilities" must be mandated only for the "power 
tools", and be separate conformance classes or a separate standard.

[It is my personal belief that the validation capabilities should be a 
conformance class and the configuration capabilities should be a 
separate standard.  But I also believe, as I said to Howard in Bath, 
that SC4 does not currently have the resources to make a separate 
standard.  I just don't want the simple mapping to be delayed another 
year while we resolve the configuration issues.  Configuration and 
validation have already cost this project one full year.]

-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."