[wg11] Part 28 features we could lose

[Lothar Klein]

Ed,

> ...
> Why did you write your email in English and not German?  Because most of
> the community you want to influence, and from whose knowledge and 
> available resources you wish to profit, does not understand German. 
> That is why we translate EXPRESS to XML Schema.

I'm still trying to understand for what all this XML stuff is good
for. The arguments you listed are not too convincing for me.

In fact it was a relatively easy task for us to extend our SDAI
toolkit for part28ed2 import and export in a generic way (no
configuration). Generic means that it is realised for any EXPRESS
schema and without having the corresponding XML schema. This is
possible because p28 defines (besides other things) how to map express
data to xml data.

I don't belive that people would ever like to see EXPRESS-XML
data on their monitors. PDTnet proved that it is possible but I have
doubts that people will ever like to work this way.

However while speaking with several CAx-vendors I see that the main
attraction for them is to use one of the XML-APIs to read/write
EXPRESS defined data without having the need to use one of the EXPRESS
toolkits. If part28 solves this problem (and it seems it does) then
there is a real benefit. But again - at least the low level XML toolkits
don't need very complex XML schemas for this job. Just to know what is
the id of an entity instance to be able to find it in an XML document
is almost sufficient for this task.

When comparing XML-APIs with SDAI for EXPRESS defined data I would say:
- the XML-APIs are very generic. You can do everything in principle
  and it is no problem with them to read/write some EXPRESS-XML data.
  But when the job gets more complex people will soon face various
  limitations such as memory consumption, missing usedin methods etc.
- SDAI, its language bindings and implementation results in optimised
  interface for EXPRESS defined data. They are of a similar complexity
  than those XML-APIs, but they can do the job much more efficient.

Some problems which might need further investigation:
- We heard that some XML tools have problems with the EXPRESS-XML
 schemas. Are these principle problem or will they be solved with a
 next version of the toolkit? And which toolkit these are?
- is there something we can do on multi leaf complex entities (ANDOR)
 to avoid listing them all in the XML-Schemas? But maybe it is even
 better to keep what we have right now because it will force people to
 specify which ANDOR combinations they really want.
 (only a very small fraction of the possible combinations in STEP are
 really useful)
 
>> One argument for this (if it is possible at all) is that all the
>> current approaches on mapping EXPRESS-to XML do not provide
>> sufficient validation as required by EXPRESS schemas, and what is the
>> worth of some "validation" if it is not complete?

> Define "complete".  What is the worth of validation if it guarantees
> that the data meets all the constraints of the EXPRESS schema, but the
> data makes no business/engineering sense?  EXPRESS schemas are just a
> further position on the data validation curve, and recent add-ons to XML
> schema are trying to do similar things for XML.  The ontology work is
> beyond EXPRESS in this area, and it will be fitted to XML and XML schema
> in its own way, or perhaps it will be the replacement for XML schema in
> 2007, and we will be talking about yet another migration path...

EXPRESS has quite good capabilities to define rules to ensure that
business/engineering processes can work smooth. Only the data models
we have today are not always of the needed quality - but things become
better from version to version

Lothar


PS: I'm suggesting a yes vote for p28ed2 without comments