[wg11] Minutes of Part 21 E3 DIS testing telecon on June 5, 2914
thomas thurman
thomas.r.thurman at imonmail.com
Sat Jun 7 22:13:12 EDT 2014
Created bugzilla #5069 to capture details,
added a sample population to the bug.
Tom
>On Jun 7, 2014, at 5:46 PM, thomas thurman <thomas.r.thurman at imonmail.com> wrote:
> Addendum for Fahrenheit discussion.
> Comments on current approach in part 41 and AP 214:
> 1-part 41 is specific that any unit that is related to a unit specified in part 41 shall be a ‘conversion_based_unit’.
> 2-conversion_based_unit only converts the magnitude but does not provide an offset.
> 3-The use of ISO 13584-20 for such a simple case is long agreed overkill; the example in part 41 F 4.4 has EXPRESS
> errors (
> a-the expression_conversion_based_unit shall be a conversion_based_unit (see (1) above.) and
> b-the attribute redeclaration in e.g., named_unit_variable.associated_variable_environment is invalid.).
> 4-AP 242 ed1 did not include a structure to support Fahrenheit unit exchange.
> 5-AP214 used a context_dependent_unit which is invalid (see (1) above). As noted above this was NOT promoted to
> AP 242.
> 6-After several attempts to discover a URL,URN for Fahrenheit I gave up and am proposing that SC4 define its own
> (NIST has a guide that includes a definition of Fahrenheit as a note (I think) but does not provide a URN or URL.).
> (There are multiple conversion calculators on the web but I am not convinced of their persistence.
> In any event use of a conversion calculator opens up its own can of worms.)
>
> ==========proposed solution:===========
>
> add a subtype of conversion_based_unit, conversion_based_unit_with_offset to provide the offset.
>
> =========current:============
>
> A conversion_based_unit is a type of named_unit that defines a unit on the basis of a measure_with_unit.
> NOTE The value_component attribute of the measure_with_unit defines the conversion factor.
>
> EXAMPLE An inch is a conversion_based_unit. It is from the Imperial system, its name is "inch", and it can be related to the si_unit, millimetre, through a measure_with_unit whose value is 25.4 millimetre. A foot is also a conversion_based_unit. It is from the Imperial system, its name is "foot", and it can be related to an si_unit, millimetre, either directly or through the unit called "inch".
>
> EXPRESS specification:
> *)
> ENTITY conversion_based_unit
> SUBTYPE OF (named_unit);
> name : label;
> conversion_factor : measure_with_unit;
> WHERE
> WR1: SELF\named_unit.dimensions = derive_dimensional_exponents(conversion_factor\measure_with_unit.unit_component);
> END_ENTITY;
> (*
>
> Attribute definitions:
>
> name: the label by which the conversion_based_unit is known.
>
> conversion_factor: the measure_with_unit that specifies the physical quantity from which the conversion_based_unit is derived.
>
> Formal propositions:
>
> WR1: The dimensional exponents shall be equal to those from the conversion_factor.
>
>
> =========proposed addition to part 41=========
> A conversion_based_unit_with_offset is a type of conversion_based_unit that includes a scale offset.
> EXAMPLE A Fahrenheit is a conversion_based_unit_with_offset. It is from the Imperial system, its name is “fahrenheit", and it can be related to the si_unit, degree Celsius, through a measure_with_unit whose value is 1.8 degree Celsius. The offset is 32 degree Celsius.
>
> EXPRESS specification:
>
> *)
> ENTITY conversion_based_unit_with_offset
> SUBTYPE OF (conversion_based_unit);
> offset : REAL;
> WHERE
> WR1: offset <> 0.0;
> END_ENTITY;
> (*
>
> Attribute definitions:
>
> offset: the value of the offset represented in the units of the conversion_factor inherited from the conversion_based_unit.
>
> Formal propositions:
>
> WR1: The offset shall not be zero.
>
> Note: If the offset is zero, then the supertype conversion_based_unit is used.
> =========end proposed addition to part 41=========
>
> On Jun 6, 2014, at 3:29 PM, Martin Hardwick <hardwick at steptools.com> wrote:
>
>> P21 e3 DIS Testing
>> Minutes of June 5, 2104 Telecon
>> Attendees
>> Martin Hardwick <hardwick at steptools.com>
>> Robert Lipman <robert.lipman at nist.gov>
>> Michael Benda <mjbenda at rockwellcollins.com>
>> Hedlind Mikael <mikael.hedlind at scania.com>
>> Dave Loffredo <loffredo at steptools.com>
>> Ed Paff <ejp at transcendata.com>
>> Tom Thurman <thomas.r.thurman at imonmail.com>
>> Apologies for Absence
>> Jochen Fritz <jfritz at steptools.com>
>> Nicolas Figay <nicolas.figay at eads.net>
>>
>> PMI Splitting
>> ITI has split the sp3_boxy file produced by NIST into a geometry file and a pmi file. STEP Tools has viewed the geometry file and is working on a viewer for the separated pmi file. The two files and the original NIST data can be found at the following URL:
>>
>> ftp://www.steptools.com/private/P21e3_DIS_testing/PMI/
>>
>> STEP Tools is sponsoring the development of open source programs to split and merge P21 files using the Edition 3 specification. The programs are available at the following URL: http://tinyurl.com/thundercode.
>>
>> ZIP Assemblies
>> No visible progress has been made on this test case since the last telecom, but the PMI merge and split code is being updated to handle this case as well.
>>
>> ftp://www.steptools.com/private/P21e3_DIS_testing/ZIP_Assembly/
>>
>> In the last telecom:
>> · We decided the sub-tree directory names should include the NUAO identifier(s) for their corresponding node in the assembly tree.
>> · We learned that the LZMA algorithm has been shown to make STEP files three times more compressed than the more commonly used deflate algorithm, but at the cost of an increase in the compression time.
>> · We learned that each compressed file is required to document the algorithm used for its compression in its header and that different components in the same ZIP can used different compression algorithms.
>> · We recommended that the choice of the best compression algorithm should be left to the end user and that the standard should be silent on the matter.
>>
>>
>> Unit Definitions
>> The unit definitions have been merged into a single file called units.stp.
>>
>> ftp://www.steptools.com/private/P21e3_DIS_testing/Units/
>>
>> We continued our discussion on whether unit references should be encoded as a URL or a URN. The following two lines of code show equivalent URL’s and URN’s.
>>
>> <http://standards.iso.org/iso/10303/tech/reference_data/41/si_base_units.stp#METRE>;
>> <urn:iso:std:iso:10303:-41:tech:unit:metre>;
>>
>> Explanation of URN:
>> urn Indicates this URI is a URN, instead of the more common URL (http)
>> iso URN namespace (other examples are oid, usbn)
>> std ISO standard
>> iso originating organization (other examples are iec, iso-ies, iso-cie)
>> 10303 STEP standard
>> -41 part of multipart standard (hyphens required)
>> Tech associated or embedded resource defined by committee that created the standard
>> <the rest> unspecified -- controlled by committee.
>>
>> In the above example, the URN has small advantage over the URL but perhaps the following URN will be acceptable because a file does not have to exist to define a URN.
>>
>> <urn:iso:metre>;
>>
>> It is also conceivable that the following URN might be acceptable even though there are currently small technical issues stopping the deployment of unit definitions for a Fahrenheit measure in a STEP file.
>>
>> <urn:iso:Fahrenheit>;
>>
>> We further discussed the requirements if all the unit definitions are to be defined in STEP files. The definition of literal constants such as PI, and EXPRESS constants such as negri_pi, have both led to extensive additions to the edition 3 format for which other strong use cases are currently lacking.
>>
>> On the other hand the problem might be that we have not been sufficiently ambitious. It was pointed out that if constants can be defined then we are close to allowing expressions to be defined. The use of the PLIB schema for expressions has never been very satisfactory because the expressions are too hard to read when encoded into the STEP files. However, if Part 21 has an expression evaluation capability (probably in the anchors) then potential STEP applications such as parametrics and construction history might become more tractable. One interesting possibility might be to use Modelica as the expression language.
>>
>> Digital Signatures
>> STEP Tools gave a demonstration of how to make a digital signature using a private key and a signing certificate and how to verify that a file has not been edited since it was signed using a public key.
>>
>> ftp://www.steptools.com/private/P21e3_DIS_testing/Digital_signatures/
>>
>> We discussed white space and the issues that might arise if a file is read into Notepad/Wordpad and converted from line-feeds to carriage returns or vice versa. These characters are explicitly excluded from the Part 21 character set so they will not be included when computing and verifying the hash value.
>>
>> We discussed supporting multiple signatures. The easiest procedure is for each signature to be applied to all of the characters that precede that signature. Thus each new signee is also verifying the signature of the previous signees.
>>
>> For this to be consistent it would be best if the signatures came after the END-ISO-10303-21 keyword as shown in the example on the ftp site.
>>
>> · The next conference call will be held on Friday June 27 at 4PM Paris, 3PM London, 10AM New York and 7AM Seattle.
>>
>> Action Items
>> 1. Complete the first ZIP assembly example.
>> 2. Consider the best approach for unit definitions: URN’s or URLs’?
>> 3. Consider if Edition 3 should offer any support to the definition of parametrics and if so how?
>> 4. Extend the digital signatures example to include the creation of signing certificates.
>> 5. Demonstrate signing at one site (ITI) and verification at another site (STEP Tools).
>>
>>
>> As recorded by Martin Hardwick <hardwick at steptools.com>
>>
>> <Minutes_p21e3_DIS_conference_call_05062014.docx>_______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
>
> Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.
>
>
Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.steptools.com/pipermail/wg11/attachments/20140607/efcb4e26/attachment.html>
More information about the wg11
mailing list