[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