[wg11] RE: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2

[David Price]

Ed,

I think the deprecated constructs in EXPRESS remain in the DTD so that the
syntactic equivalent of the original schema can be recreated from the XML
document. There are good reasons for that, and for what you propose.
However, at this point in time I'd leave the decprecated constructs in the
XML Schema for the Part 28 E2 annex. That would leave any semantic
transforms to a standardized metamodel of EXPRESS - which we both hope will
get underway before long.

Cheers,
David

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark at nist.gov] 
> Sent: 10 September 2004 18:02
> To: David Price
> Cc: 'STEP Open-Source'; 'SC4 WG11'
> Subject: Re: [wg11] RE: [step-os] Part 28 comment JP-5 meets 
> EXPRESS Ed.2
> 
> 
> David Price wrote:
> 
> >  I suggest falling back to one of my earlier suggestions:
> > 
> > Include the STEPMod DTD as an informative annex in Part 28 
> E2 - or run 
> > it through an XML tool that translates DTDs to XML Schema 
> and include 
> > that XML Schema instead.
> 
> I agree with this, in the latter version.  Part 28 v2 should 
> contain an 
> XML Schema description of the exchange form, not a DTD.  Also I think 
> you want a human expert to review the automatic translation 
> and improve 
> the resulting XML schema with the proper use of XML data types.
> 
> I agree that the Annex should be informative.
> 
> I agree that no text is required, *so long as* there is 
> <documentation> 
> in the XML schema that relates the tags to the Part 11 terms.
> 
> > Below is the extract of that DTD for entity data types and 
> global rule 
> > so you can see its approach :
> > 
> > <!ELEMENT entity (description?, explicit*, derived*, inverse*, 
> > unique*, where*, graphic.element?)> <!ATTLIST entity
> > 	name NMTOKEN #REQUIRED
> > 	abstract.entity (YES | NO) "NO"
> > 	abstract.supertype (YES | NO) "NO"
> > 	supertypes NMTOKENS #IMPLIED
> > 	super.expression CDATA #IMPLIED
> 
> Asides:
> 
> (1) ABSTRACT SUPERTYPE is a proper subtype of ABSTRACT 
> ENTITY:  Abstract 
> entities *may* have "generic attributes"; abstract supertypes are not 
> permitted to.  That is the *only* difference.  An abstract 
> entity that 
> has no generic attributes is not semantically distinguishable from an 
> abstract supertype.  We should actually deprecate the use of ABSTRACT 
> SUPERTYPE.
> 
> (2) supertype expression *is* deprecated in EXPRESS Ed2, in favor of 
> SUBTYPE_CONSTRAINT, which can carry all of the same information and 
> more.  Every valid supertype expression is a valid 
> SUBTYPE_CONSTRAINT, 
> i.e.  ENTITY x <supertype expression> maps 1-to-1 to:
>    SUBTYPE_CONSTRAINT FOR (x);
>     <supertype expression>;
>    END_SUBTYPE_CONSTRAINT;
> 
> I would recommend that you think about making that transform, since 
> SUBTYPE_CONSTRAINTs for the same (x) can be *added* in other 
> modules and 
> APs that use the ENTITY type, and that gives you a uniform 
> representation of the constraint set for a given (x).
> 
> -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."
>