OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cgmo-webcgm] Draft DOM document


At 10:50 PM 6/7/2004 -0400, Benoit Bezaire wrote:
>   [...]
>
>   I doubt section 1.1.1 Relationship with XML companion file to be
>   clear enough, I'd like to hear opinions on what is missing if
>   possible.

It's a good start.  About item 1.) in 1.1.1, there are really two flavors:

1a.)  Replace existing standard ApsAttr metadata that are present in the 
WebCGM instance with new values;
1b.)  Supply standard WebCGM ApsAttr metadata to APS's in the WebCGM 
instance that contain no values.

The text says 1a now, but I think 1b is at least as important a use case 
(if not more so).

1.1.3 Comment.  see my comments (just sent to list of individuals) about 
this point in Dave's draft minutes.

Interface Metafile Comment.  I don't feel strongly about it, but the three 
attributes are cgmDescription, cgmId, cgmVersion.  Would it be better to 
call them metafileDescription, metafileId, metafileVersion, which are their 
actual names is the CGM:1999 standard?

s/Returns the Metafile Descriptor/Returns the Metafile Description (string)/

1st green box:  cgmId (metafileId) is not the file name of the metafile; it 
is the (string) parameter of the Begin Metafile element.

On Interface Node you ask:  "// should attributes be here or in another 
interface?"  Is this a matter of style, or are there significant functional 
differences?  (Can you show the alternative you have in mind?)

Out of time for now (still reading).  Maybe more later.

-Lofton.



>   If people have no objections, I'd like to propose that during the
>   call on Wednesday, we start working on the green boxes.  We have to
>   get ride of all the green boxes, they represent questions/issues
>   that need to be resolved.
>
>   Unfortunately, there are some differences between what we agreed
>   upon in Cologne and what is in this document.  I tried to keep the
>   number of differences to a minimum...
>
>   1) We never talked about error handling and exceptions; all DOM
>   specifications I know about throw exceptions when appropriate.  I
>   think the WebCGM DOM should also use exceptions.
>
>   2) I added an AppStructure interface because putting everything on
>   the Node interface wasn't working.  The main reason is that too many
>   APIs would have resulted in a strange behavior on the newly added
>   namespace application structures.
>
>   3) The third major change is that I've introduced
>   getAppStructureAttr, setAppStructureAttr and removeAppStructureAttr
>   to replace all the specific APS attribute calls we had enumerated.
>   If people don't like this, I'm certainly open to reverting back this
>   change.  There are two reasons why I made this switch; i) to be
>   similar to the DOM getAttribute and setAttribute methods and ii) to
>   reduce the number of API in our interfaces.
>
>   Please let me know what you think!
>
>   Regards,
>
>--
>  Benoit                 mailto:benoit@itedo.com
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]