[wg11] units of measure, from Minutes of Part 21 E3 DIS testing telecon on June 5, 2914
Martin Hardwick
hardwick at steptools.com
Wed Jun 11 06:35:11 EDT 2014
Again my purpose is to investigate how P21 e3 might help. The most we
can venture is to produce some recommendations and examples.
My summary of the previous e-mails is that the ISO namespace <urn:iso>
is jealously guarded to keep the peace between the committees. We are
never going to be able to use it to make something easy for the
implementors.
However, before giving up on URN's I would like to get opinion on the
following: Can we define our own namespaces?
We might do this for each standard, or at the level of SC4.
For example, if we decide to use URNs to define units for STEP then
1. The URN for inch might be <urn:step:inch>;
2. The URN would be mapped by appropriate wording in the appropriate
place to the URL
<http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
3. The URN would only have to have meaning for a STEP model.
We would then do the same for ifc <urn:ifc:inch> and iso15926
<urn:iso15926:inch> etc.
The appropriate wording in #2 could be words in the standards document,
or it could be a rule in the standards document telling you where to
find a server with the permitted URNs.
Martin Hardwick
Team Leader ISO STEP-Manufacturing
On 6/10/2014 8:15 PM, Thomas.r.thurman wrote:
> The purpose behind the units thing in P21 ed3 EXAMPLEs is to help move
> things forward,
> as opposed to just having examples in p41.
> The BIPM has made general quantities and units document publicly
> available, but ISO 80000-x
> is still behind a paywall which means I have to buy a copy of it to
> understand what a term means.
>
> What is the */_business_/* process for moving forward?
> Regards,
> Tom
> Sent from my iPad
>
> On Jun 10, 2014, at 4:11 PM, Martin Hardwick <hardwick at steptools.com
> <mailto:hardwick at steptools.com>> wrote:
>
>>
>> Hi Ed,
>>
>> Thanks for these comments and before anyone gets the wrong idea let
>> me state emphatically that Part Edition 3 is NOT, NOT, NOT planning
>> to define any units. We are only looking at what might become
>> possible if URI's are allowed in the Part 21 standard.
>>
>> One option for the relevant committees is to keep the status quo and
>> demand that all units are defined from first principles as is
>> currently the case in all the STEP Application Protocols. Thus every
>> time an inch is used it must be defined as being 25.4 millimeters.
>> (As an aside I wonder what would happen if a file defined an inch as
>> 25.3 millimeters. Would the software notice? Would it follow through
>> and convert all the units by the given formula. Would the result be a
>> correct model? What about the accuracy constraints? Has STEP been
>> consistent about applying the conversion across all the cases?)
>>
>> The second option is to use URL's. This is the option that is being
>> most actively investigated by the P21 e3 group. This option is
>> currently running into several small issues with respect to
>> conversion based units. As I understand it the issues are derived
>> from problems in the PLIB expression schema, but on a more personal
>> level I have always thought it crazy to encode expressions in the
>> PLIB expression schema.
>>
>> This started me thinking about the URN option in more detail. As I
>> understand it a URN is used when the systems are expected to "know"
>> the definition.
>>
>> Hence I wonder why we cannot define
>>
>> <urn:iso:inch>
>>
>> In the context of an AP242 file this would mean the current
>> definition only with the conversion GUARANTEED to be 25.4. For an OWL
>> system it would be whatever OWL systems expect and so on. It is a URN
>> so nothing has to be at the other end of the definition, but
>> something could be so STEP could say this URN is defined by the
>> definitions at the following URL (which can then be as complex as any
>> standards organization can imagine).
>>
>> I really wonder what the advantage of a convoluted URN such as
>> urn:iso:std:iso:31:term:metre might be. Does this mean that different
>> standards groups are going to define different metres?
>>
>> There is also the practical issue for system implementors of what to
>> do if someone types the URN's slightly wrong which increases as the
>> URN gets longer.
>>
>> As an implementor <urn:iso:inch> seems just about acceptable because
>> there is very small possibility that we will want to have two
>> definitions for inch in STEP files - one defined by ISO and another
>> defined by Martians <urn:mars:inch>. A more practical example might
>> be the definition of pint which is different between the UK
>> <urn:iso:uk:pint> and the USA <urn:iso:usa:pint>. I can see that ISO
>> might shy away from making this kind of distinction, but in this case
>> can STEP should define its own name space <urn:step:inch> for its own
>> STEP files.
>>
>> Thanks for your attention. If we are going to have to write URN's
>> that are as long and convoluted as the URL's then we may as well
>> stick with the URL's, so I am hoping there is a better solution.
>>
>> Martin
>>
>>
>>
>> On 6/10/2014 4:42 PM, Barkmeyer, Edward J wrote:
>>> Signature
>>>
>>> Martin,
>>>
>>> I agree that fuddling with Part 41 representations of measurement
>>> units that should have reference IRIs is “so 1990s”. But moving on
>>> requires a wider commitment.
>>>
>>> urn:iso: ... is a well-defined identifier form, and ISO CS is the
>>> registry for it. See IETF RFC 5141.
>>> (http://www.rfc-editor.org/info/rfc5141)
>>>
>>> Some of these units are defined terms in ISO 31, ISO 1000 and ISO
>>> 80000. As a consequence they have a well-defined URN per the RFC.
>>>
>>> For example, the URN for ‘metre’ is (I think):
>>>
>>> urn:iso:std:iso:31:term:metre
>>>
>>> It is doubtless the case that one of the ISO measurement units
>>> standards defines cm/s, but it is unlikely that any defines
>>> ‘furlong’ or ‘inches per second’. That is why Part 41 has the
>>> conversion_based_unit construct.
>>>
>>> SC4 has authority from ISOCS to define ISO URNs by attaching
>>> :tech:<whatever> to any (Part of any) SC4 developed standard
>>> identifier, with the proviso that these identifiers are, in fact,
>>> defined in the technical specification. It is in fact possible for
>>> Part 21 to specify URNs of the form:
>>>
>>> urn:iso:std:iso:10303:tech: xxx
>>>
>>> without identifying the Part number. I suspect that WG12 would
>>> consider it inappropriate for Part 21 to contain such
>>> specifications, however.
>>>
>>> Further, there is an issue in WG3 to align ISO 15926-4 with ISO
>>> 80000 and perhaps to incorporate some elements of NASA QUDT, which
>>> is an OWL ontology of every unit NASA has ever dreamed of using,
>>> based on a fundamental ontology that mirrors ISO 80000 and the
>>> International Vocabulary for Measures (VIM). So, it may be possible
>>> that these desired “common units” have the form:
>>>
>>> urn:iso:std:iso:15926:-4:tech:class:INCHES_PER_SECOND
>>>
>>> or something the like. It is definitely the intent of WG3 that they
>>> will have a URI
>>>
>>> http://iso.org/std/iso/15926/-4# INCHES_PER_SECOND
>>>
>>> or something the like (and that is only because W3C decided that
>>> http: is the universal prefix for IRIs, and no longer denotes a
>>> protocol). But WG3 would really prefer that QUDT was a
>>> referenceable standard in its own right, with its own IRI path.
>>>
>>> With the above as background, it is important for SC4 to avoid
>>> participating in the construction of another cottage industry. It
>>> would be a “good thing” for SC4 to bring its interested parties to a
>>> common table and come up with a common solution to this problem for
>>> SC4 specifications, instead of one-off conventions for the favorite
>>> technology of each Working Group.
>>>
>>> -Ed
>>>
>>> *From:*wg11 [mailto:wg11-bounces at steptools.com] *On Behalf Of
>>> *Martin Hardwick
>>> *Sent:* Tuesday, June 10, 2014 10:22 AM
>>> *To:* Thomas Liebich; wg11
>>> *Subject:* Re: [wg11] Minutes of Part 21 E3 DIS testing telecon on
>>> June 5, 2914
>>>
>>> Hi Thomas,
>>>
>>> Thanks for this feedback.
>>>
>>> I am growing in favor of using a simple URN for all the "famous"
>>> (well known units).
>>>
>>> Hence, we might have in the reference section of a P21 e3 file:
>>>
>>> #10=<urn:iso:metre>;
>>> #20=<urn:iso:inch>;
>>> #30=<urn:iso:centigrade>;
>>> #40=<urn:iso:Fahrenheit>;
>>> #50=<urn:iso:furlong> ;
>>> #60=<urn:iso:inches-per-second>;
>>>
>>> And so on for all the units that the standards want to recognize.
>>> There would not need to be any files to define these units (but
>>> there could be). Software systems would be expected to "know" them
>>> from the URN and that would include knowing how to convert between
>>> them.
>>>
>>> (Without benefit of a conversion based expression - oh my gosh what
>>> will happen if there is an apocalypse and the only people left are
>>> idiot savant nerds who only know how to follow mathematical
>>> expressions and cannot remember any units except the ones stored in
>>> the NIST library which was the only building in Washington to
>>> survive the catastrophe of course) - Yes I will be made to regret
>>> this statement.
>>>
>>> Martin
>>>
>>>
>>> On 6/10/2014 9:29 AM, Thomas Liebich wrote:
>>>
>>> Dear all,
>>>
>>> only as a side remark. During our IFC (ISO16739) developments we
>>> faced the same issue - a derived unit involving factor and
>>> offset cannot be defined with the current conversion_based_unit.
>>>
>>> So we added a subtype to IFC4, which essentially defines the
>>> same, as the proposed extension here for P41.
>>> See
>>> http://www.buildingsmart-tech.org/ifc/IFC4/final/html/link/ifcconversionbasedunitwithoffset.htm
>>>
>>> One important consideration: you need to determine, whether to
>>> apply the offset before or after applying the factor. We decided
>>> to apply it after.
>>>
>>> hope it gives another insight,
>>>
>>> regards
>>> Thomas
>>>
>>> --
>>>
>>> Am 08.06.2014 01:46, schrieb thomas thurman:
>>>
>>> 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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.named_unit> that
>>> defines a unit on the basis of a *measure_with_unit*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.measure_with_unit>.
>>>
>>>
>>> NOTE The *value_component*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.measure_with_unit.value_component> attribute
>>> of the *measure_with_unit*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.si_unit>,
>>> millimetre, through a *measure_with_unit*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.si_unit>,
>>> millimetre, either directly or through the unit called "inch".
>>>
>>> _EXPRESS specification:_
>>>
>>> |*)|
>>> |ENTITY conversion_based_unit|
>>> | SUBTYPE OF (|named_unit
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_schema.htm#measure_schema.named_unit>|);|
>>> | name : |label
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C25_schema.htm#support_resource_schema.label>|;|
>>> | conversion_factor : |measure_with_unit
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_schema.htm#measure_schema.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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Csupport_resource_schema%5Csupport_resource_schema.htm#support_resource_schema.label> by
>>> which the *conversion_based_unit* is known.
>>>
>>> *conversion_factor: *the *measure_with_unit*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.conversion_based_unit.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*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.si_unit>,
>>> degree Celsius, through a *measure_with_unit*
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.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 : R
>>> <file:///%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_schema.htm#measure_schema.measure_with_unit>EAL;|
>>> |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 <mailto:hardwick at steptools.com>> wrote:
>>>
>>>
>>>
>>> *P21 e3 DIS Testing*
>>>
>>> Minutes of June 5, 2104 Telecon
>>>
>>>
>>> Attendees
>>>
>>> Martin Hardwick <hardwick at steptools.com>
>>> <mailto:hardwick at steptools.com>
>>> Robert Lipman <robert.lipman at nist.gov>
>>> <mailto:robert.lipman at nist.gov>
>>> Michael Benda <mjbenda at rockwellcollins.com>
>>> <mailto:mjbenda at rockwellcollins.com>
>>> Hedlind Mikael <mikael.hedlind at scania.com>
>>> <mailto:mikael.hedlind at scania.com>
>>> Dave Loffredo <loffredo at steptools.com>
>>> <mailto:loffredo at steptools.com>
>>> Ed Paff <ejp at transcendata.com> <mailto:ejp at transcendata.com>
>>> Tom Thurman <thomas.r.thurman at imonmail.com>
>>> <mailto:thomas.r.thurman at imonmail.com>
>>>
>>>
>>> Apologies for Absence
>>>
>>> Jochen Fritz <jfritz at steptools.com>
>>> <mailto:jfritz at steptools.com>
>>>
>>> Nicolas Figay <nicolas.figay at eads.net>
>>> <mailto: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>
>>> <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>
>>> <mailto:hardwick at steptools.com>
>>>
>>> <Minutes_p21e3_DIS_conference_call_05062014.docx>_______________________________________________
>>> wg11 mailing list
>>> wg11 at steptools.com <mailto: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.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> wg11 mailing list
>>>
>>> wg11 at steptools.com <mailto:wg11 at steptools.com>
>>>
>>> http://lists.steptools.com/mailman/listinfo/wg11
>>>
>>> --
>>>
>>> beste Grüße / kind regards
>>>
>>> Dr.-Ing. Thomas Liebich
>>> Geschäftsführer / Director
>>>
>>> ------------------------------------------------------------------------
>>>
>>> AEC3 Deutschland GmbH
>>> AG München, Handelsregister HRB 164221
>>> Geschäftsführer: Dr. Thomas Liebich, Kerstin Hausknecht
>>>
>>>
>>>
>>> Wendl-Dietrich-Str. 16, D-80634 München
>>> Tel: +49-89-18703223
>>> Fax: +49-89-18703224
>>>
>>>
>>>
>>> E-Mail: tl at aec3.de <mailto:tl at aec3.de>
>>> Internet: www.aec3.de <http://www.aec3.de>
>>>
>>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter
>>> Dateien) ist vertraulich und nur für den Empfänger bestimmt.
>>> Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist
>>> Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder
>>> Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem
>>> Fall unverzüglich den Absender und löschen Sie die E-Mail
>>> (einschließlich etwaiger Anhänge) von Ihrem System. | /This
>>> email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the
>>> intended recipient please delete it from your system and notify
>>> the sender. You should not copy it or use it for any purpose nor
>>> disclose or distribute its contents to any other person./
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> wg11 mailing list
>>>
>>> wg11 at steptools.com <mailto:wg11 at steptools.com>
>>>
>>> http://lists.steptools.com/mailman/listinfo/wg11
>>>
>>
>> _______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com <mailto:wg11 at steptools.com>
>> http://lists.steptools.com/mailman/listinfo/wg11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.steptools.com/pipermail/wg11/attachments/20140611/0a6c64cb/attachment.html>
More information about the wg11
mailing list