RE: [cgmo-webcgm] New draft snapshot

[DULUC Franck <franck.duluc@airbus.com>]

Title: RE: [cgmo-webcgm] New draft snapshot

Benoît,

Just a quick remark:

Within some sections like the following one:

"Another benefit of the XML companion file is to carry application specific data (or metadata) concerning a WebCGM illustration. This information is expressed using namespace attributes and elements in the XML companion file. The WebCGM DOM provides method to load the XML metadata into the user agent's object model. Using the DOM, a user can gain access to the metadata. Here is an example to better illustrate the concept, let us assume we are working with the following WebCGM document (expressed in clearText encoding):"

You are using sometimes the terms "WebCGM DOM" and "DOM". My thought is, tough it is very heavy to read, the "WebCGM DOM" shall be used everywhere (no implicit meaning), if not done some implementors may understand that another DOM will take in charge the expected behavior. Maybe an alternative is to state at the beginning that within the scope of the document DOM is meaning the WebCGM DOM and then states that any reference to "other DOMs" will be done using clear identification of the given DOMS (for instance "XHTML DOM").

I have just finished the reading of the last snapshot (back from holiday this morning), I do not have other strong comments on the content of it. I would be pleased to see it really implemented for our future uses.

Regards,

Franck DULUC
Technical Data Research Manager
Customer Services - SDND
AIRBUS France

Phone: +33 (0)5 61 18 19 16
Fax: +33 (0)5 61 93 59 44
mailto:franck.duluc@airbus.com

Address:
BP D0611, 316, route de Bayonne
31060 TOULOUSE Cedex, FRANCE

-----Message d'origine-----
De : Benoit Bezaire [mailto:benoit@itedo.com]
Envoyé : mardi 3 août 2004 19:50
À : CGM Open WebCGM TC
Objet : [cgmo-webcgm] New draft snapshot

Hi all,

  Attached you will find a new draft of the spec.  There are no green
  boxes in this one, which is a good sign.

  The changes are:
  - Removed the Hyperlink interface.  I couldn't get Hyperlinks
  working with the 'attributes' attribute of the Node interface since
  Hyperlinks were not deriving from Node.  Instead, I propose that
  Hyperlinks and 'name's be expressed using DOMStringList objects.

  - Changed the datatype of the 'value' attribute on the Attr
  interface from DOMString to DOMStringList since we have several
  attributes in WebCGM that can take more than a single value.

  - Changed setters/getters on the AppStructure interface to handle
  DOMStringList.

  - Added RemoveEventListener on the Picture interface.

  - Removed linkuri specific APIs from DOM.

  - 'src' attribute was moved from getWebCGMDocument interface to the
  Metafile interface (this is closer to what other technologies are doing).

  - Changed 'number' datatype to a 'float'.  Number was
  underspecified.

  - Changed 'integer' datatype to 'unsigned short'.  Integer was
  underspecified.

  - Modified wording for 'namespaceURI', 'prefix' and 'localName'.

  - Added setAttributeNS().  We were able to set WebCGM attributes but
  not the non-WebCGM one.

  - 'intensity' is still intensity; here's why...  I tried to come up
  with other names (whiteout, fadeout, lightness, etc...), but all of
  them in my opinion were prone to be misinterpreted.
  What I did do however, is to make the wording of the spec very clear
  that this attribute makes colors whiter.  I've inserted the equation
  and added an example to remove any misinterpretation of the
  equation.  If this attribute name is unacceptable to some group
  members I'll be happy to change it to something else once consensus
  is reached in emails.

  - Added 'pictid' to the Picture interface.  Itedo noticed that
  pictid is used in linkuris but that they were currently no way
  for accessing a pictid given a Picture object.  It is currently set
  as a readonly attribute.

  Please send comments regarding latest draft to the mailing list.

  My next document will likely be one proposing a set of rules and
  pseudocode for the applyCompanionFile method.

--
 Benoit                 mailto:benoit@itedo.com

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.