[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 12:56:19 EDT 2014
On 6/11/2014 12:39 PM, Barkmeyer, Edward J wrote:
> Signature
>
> Martin,
>
> Why is:
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
>
> less “convoluted” than: urn:iso:std:iso:31:term:metre
>
> ???
>
You tell me. I want to use <urn:step:inch>
As implementors we have found that less typing means less scope for
mistakes.
If there is going to have to be lots of typing then
<http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
<http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
is better than urn:iso:std:iso:31:term:metre because there are lots of
ways to check for badly type URL's and hardly any to check a badly typed
URN.
Your URN requires me to remember:
1. Type iso twice
2. The standard number is 31
3. The concept being defined is a term
As an implementor I can do all this. Just look at what we did for units
in Part 21 Edition 1 and 2.
Martin
The http: form just uses a different ISO CS directive for formulating
IRIs, which is “jealously guarded” by ISO CS in exactly the same way!
>
> In both cases, ISOCS specifies what everything up to the “tech” part
> must be, and the SC gets to define what follows.
>
> The point of the ISO URNs of the form above is that MERELY by having
> the term defined in an existing ISO standard, there IS a standard IRI
> for the term. And if multiple standards define “metre”, then it is
> very important that you know WHICH meaning is intended by the reference!
>
> Why would it be better for ISO 10303 to define what it means by “inch”
> than what some industry reference standard defines “inch” to mean? Do
> I have to find a different IRI if I am using an ASTM standard? or an
> API standard?
>
> The problem is to get a reference standard that defines the
> “conversion based units” (English measure, et al.) that we want to be
> able to use, and then to use one of the ISO-specified forms for
> creating the corresponding IRI, whether it begins http: or urn:.
> Enabling such things is exactly why ISOCS went to the trouble of
> registering the URN and URL forms and publishing the corresponding
> directives. And if the reference standard is not an ISO standard, then
> we will be bound by whatever URI syntax that particular SDO set up.
> So, if urn:ifc, or http://ifc.org/, is an ICANN registered prefix, and
> the IFC defines urn:ifc:inch, or whatever “convoluted” form IFC
> decides on, we could use that and be done.
>
> The point of all this is that the references for constructing IRIs are
> already in place. What is necessary is the **standard** that defines
> the terms you want to use, so that the IRI that refers to that term in
> that standard can be employed. Stop worrying about the IRIs and
> figure out where/what the reference standard is to be. By way of
> assisting in this, I have put in a request to a NIST SI/BIPM person
> to identify an appropriate specification for English measures, but I
> have not yet received a response.
>
> -Ed
>
> *From:*Martin Hardwick [mailto:hardwick at steptools.com]
> *Sent:* Wednesday, June 11, 2014 6:35 AM
> *To:* Thomas.r.thurman
> *Cc:* Barkmeyer, Edward J; Thomas Liebich; wg11; Palmer, Mark E. Mr.;
> magne.valen.sendstad at gmail.com
> *Subject:* Re: [wg11] units of measure, from Minutes of Part 21 E3 DIS
> testing telecon on June 5, 2914
>
>
> 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>
> <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:
>
> 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#
> <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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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%5C%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/d7cb6fde/attachment.html>
More information about the wg11
mailing list