Re: [unitsml] Current Meeting Ends Wednesday - Please Participate

["Peter J. Linstrom" <peter.linstrom@nist.gov>]

All,

  I'm sorry I was unable to attend the meeting on
the 25th. I would like to add the following comments
based on the audio recoding of the meeting.

* At 22 minutes into the recording there is a discussion
  of using Numeric Character References (NCRs) for characters
  outside the normal 7-bit ASCII range. In this case there
  was a discussion of the theta symbol which represents the
  temperature dimension. I would like to add the following:

  XML schema allows native use of the Unicode characters,
  but the document must be encoded in a manner that allows
  for representation of these characters. Since many people
  don't have UTF-8 or UTF-16 editors I think the best idea
  is to keep the schema in 7 bit ASCII (which is also valid
  UTF-8) and use NCRs for all characters which are outside
  the ASCII range. The schema contains very few characters
  outside the ASCII range, so this should not be a problem.
  There is only one non-ASCII character in the current schema:

  unitsmlSchema-0.9.11.xsd line 49, column 97: capital A with ring

  This character is currently represented by two bytes (since
  the schema is un UTF-8). Switching to Å would make the
   schema 7-bit clean. Please note that replacing a character
  by an NCR has no real meaning and making a 7 bit clean
  schema places no restrictions on instance documents that
  use the schema.

* At 23 minutes into the discussion there is a mention of
  the use of the micro sign for the "micro" prefix.

  I would like to add that while this sign is appropriate
  for presentation of data (physical markup), it is wise
  to use the ASCII u for representation of data (logical
  markup). This is simply because of the convenience of
  using ASCII character. End users should never see a "u"
  used as a prefix.

* At 26 minutes into the discussion it was suggested that
  the "Item" element be removed from the "Dimension" element
  in the first release of UnitsML. At 30 minutes a more
  comprehensive discussion of handling objects as units
  was started. I would like to add the following:

  I believe that the handling of objects as units could
  be improved in UnitsML. I think that we should strive
  for the following:

  1.) To make it clear when this is being done (so it
      can be readily suppressed by people that don't
      want it).

  2.) There should be only one way to do this. If we don't
      allow this people will either not use UnitsML or
      use some jury-rigged approach to try to do this.

  In this regard I would like to suggest the following:

  * Remove the "item" entry from the list of enumerated
    root units for the "EnumeratedRootUnit" element. This
    will prevent "EnumeratedRootUnit" from being used to
    introduce objects as units.

  * Create a new element called "ExternalRootItem" which
    would be parallel to "EnumeratedRootUnit" and
    "ExternalRootUnit". This element would have essentially
    the same attributes as "ExternalRootUnit" except
    that the "source" attribute should point to a
    "NonUnitItem" element (see below). This will remove
    "ExternalRootUnit" as a way to introduce objects
    as units.

  * Create a new top-level element called "NonUnitItem" to
    define items that are not really units but sometimes are
    treated as such (e.g., six-packs, neutrons, customers,
    etc.) This element should have attributes that specify
    the name, description, and language. This element will
    be referred to by "ExternalRootItem" (see above) and
    "Item" elements (see below).

  * Modify the proposed "Item" element for dimensions so
    that it points to a "NonUnitItem" element. This will
    make handling of objects as units consistent in root
    unit definitions and in dimension specifications.

  Please note that the names I have made up for the new
  elements can probably be improved. I choose the name
  "NonUnitItem" to make clear that such objects are not
  traditional units of measure; that name may be more
  political than practical.

* At 47 minutes into the discussion, there was a brief
  discussion about referring to the NIST UnitsML site.
  I think that as an OASIS effort all URLs in the
  documentation should eventually point to OASIS. I
  believe the only reason the examples in the
  documentation point to NIST is that a URN has not yet
  been obtained from OASIS. I don't think OASIS would
  want its recommendation canonically hosted on
  someone else's servers. Of course it is possible
  (if not probable) that I misunderstood the discussion
  on this issue.

  I hope that the committee members find the discussion
above to be of some use.

Peter

================================================
Peter J. Linstrom
NIST, Physical and Chemical Properties Division
Phone: (301) 975-5422
================================================


----- Original Message ----- 
From: <carlisle@nist.gov>
To: <unitsml@lists.oasis-open.org>
Cc: <Robin.Barker@npl.co.uk>
Sent: Tuesday, July 01, 2008 10:27 AM
Subject: [unitsml] Current Meeting Ends Wednesday - Please Participate


> As a reminder, the current UnitsML TC meeting ends Wednesday, July 2. 
> Please participate by email if you have not already done so.  (Even a "no 
> comment" remark will do.)
>
> Notes from the teleconference portion are here:
> http://www.oasis-open.org/apps/org/workgroup/unitsml/download.php/28681/telecon20080625.pdf
>
> And the audio can be heard here:
> http://www.oasis-open.org/committees/download.php/28678/20080625_8kbps.wma
>
> -Mark Carlisle