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

[David Price]

Ed,

Very good point about Part 28 E1 DTD for EXPRESS not supporting EXPRESS 2.
Given that, 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. As I've also mentioned, the STEPMod DTD uses very familiar
terms from Part 11 so I actually don't think there's any need for text to
describe what the elements are for... it's obvious if you know Part 11. By
definition, anyone implementing Part 28 E2 must be EXPRESS-literate. I
suggest an informative annex for two reasons: 1) other EXPRESS tool vendors
have not yet implemented the DTD and 2) the STEPMod developers will be less
concerned about SC4 standardizing something for an unintended purpose. I
grant that there are also good reasons to make it normative, but I expect
that would force people to review it seriously and want to change it.

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
>

<!ELEMENT rule (description?, algorithm?, where+)>
<!ATTLIST rule
	name NMTOKEN #REQUIRED
	appliesto NMTOKENS #REQUIRED
>

<!ELEMENT algorithm (#PCDATA)>

Would this satisfy JP-5?

FYI, the graphic.element is an extension allowing an EXPRESS-G diagram to be
related to an entity type. As I said earlier, this DTD was aimed at being
part of a system for producing documentation. These extensions might be
useful to developers, and as long as the annex is informative, I see no
reason to remove them.

With respect to its use for other purposes, I'll add that this DTD is the
basis for the hardcoded Part 28 E2 EXPRESS-to-XML Schema that we implemented
and discussed at the STEP meetings. I've also used it for EXPRESS to UML
translations based on a subset of Part 25 and it seems sufficient.

Cheers,
David

> -----Original Message-----
> From: step-os-bounces at ned.gsfc.nasa.gov 
> [mailto:step-os-bounces at ned.gsfc.nasa.gov] On Behalf Of Ed Barkmeyer
> Sent: 10 September 2004 16:35
> To: SC4 WG11; STEP Open-Source
> Subject: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
> 
> 
> All,
> 
> With respect to JP-5, we decided in Groton (in the absence of 
> Japanese 
> or UK or Norway representatives) to let Part 28 v1 stand as 
> an ISO TS, 
> with the "parsed exchange of EXPRESS models" as specified in 
> Annex C of 
> that Edition.
> 
> Per the previous email, that probably does not meet the 
> intent of JP-5.
> 
> But, since Part 28 v1 Annex C is a direct explosion of the 
> Part 11:1994 
> *grammar* into XML, there is another problem.  In Part 11:2004, that 
> grammar has changed in a number of places, which causes the 
> EXPRESS Ed2 
> *parse* to be somewhat different from the EXPRESS v1 parse, 
> even for an 
> EXPRESS corpus that conforms to both grammars.  That makes the use of 
> Part 28 v1 Annex C very difficult to explain!
> 
> Further, because of the EXPRESS Ed.2 introduction of ABSTRACT 
> ENTITY and 
> "generic attributes", EXTENSIBLE types, and attribute RENAME, most of 
> these grammar changes affect the parse of entities, 
> attributes and data 
> types!  That means that the most important use of the v1 mapping is 
> disaligned with the Part11 Ed2 grammar!  So in answer to David's 
> question, this is a strong reason why not.
> 
> The P28v1 mapping applies only to an EXPRESS Ed1 schema, 
> using the now 
> "provisionally retained" EXPRESS Ed1 (and its grammar) to 
> interpret the 
> XML elements.
> 
> I don't see that SC4 can continue to support the Part 28 v1 
> mapping as 
> relevant, particularly for the exchange of "module schemas".  And I 
> don't believe that "use Part 28 v1 Annex C" is in any sense a 
> satisfactory resolution of JP-5.
> 
> -Ed
> 
> P.S.  Sorry for the belated epiphany.  I had to say the word 
> "parse" in 
> the email to Tanaka-san, before I realized what the problem was.
> 
> P.P.S.  Note also that this is a strong argument for the meta-model 
> concept hidden in the STEPmod representation.  EXPRESS v2 is 
> semantically an upward-compatible extension of EXPRESS v1, and the 
> language is also an upward-compatible extension.  But the 
> *grammar*, as 
> a set of production rules, is *not* an upward-compatible 
> extension.  And 
> because the Part 28 v1 mapping represents the production 
> rules verbatim, 
> it is now useless.  (For Josh's benefit, I would say that this is a 
> doc-head thing -- a grammar is a corpus model, not a content model.)
> 
> -- 
> 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."
> 
> _______________________________________________
> step-os mailing list
> step-os at step.nasa.gov http://step.nasa.gov/mailman/listinfo/step-os
>