Re[2]: [cgmo-webcgm] New draft snapshot

[Benoit Bezaire <benoit@itedo.com>]

Hi Franck,

I hope you enjoyed your time off!

I agree with you, I'll sweep the document and make sure to use "WebCGM
DOM".  We don't want to confuse readers.

-- 
 Benoit   mailto:benoit@itedo.com

 
Monday, August 9, 2004, 10:35:02 AM, DULUC wrote:

DF> Benoît,

DF> Just a quick remark:

DF> Within some sections like the following one:

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

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

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

DF> Regards,

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

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

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



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


DF> Hi all,

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

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

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

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

DF>   - Added RemoveEventListener on the Picture interface.

DF>   - Removed linkuri specific APIs from DOM.

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

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

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

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

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

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

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

DF>   Please send comments regarding latest draft to the mailing list.

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