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] Re:


see inline (if you can find it in this mess...)

>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Thursday, July 08, 2004 6:21 PM
>To: Benoit Bezaire
>Cc: cgmo-webcgm@lists.oasis-open.org
>Subject: Re: [cgmo-webcgm] Re:
>
>
>At 11:18 AM 7/8/2004 -0400, Benoit Bezaire wrote:
>>Tuesday, July 6, 2004, 6:40:05 PM, Lofton wrote:
>>[...]
>>LH> If entities are allowed, then I think "yes".  Suppose the viewer DOM
>>LH> implementation builds and maintains the DOM tree including
>the application
>>LH> metadata.  If entities have been used in the latter, how can the DOM
>>LH> implementation possibly be of any use if the entities aren't resolved?
>>
>>LH> (Question...  I don't recall -- what if anything does
>standard DOM2/3 say
>>LH> about it?)
>>I'll have to check, I'm really not an expert on this matter.  If
>>someone had a small example we could all look at, it could help.
>
>I'm travelling and a bit short of focus, so maybe later.  But
>conceptually,
>imagine that an application parameterizes some aspect of a companion file,
>and uses an entity to define the parameter value.  E.g, by changing the
>value of the entity, perhaps for example the model number of an aircraft
>(and associated data file links) are changed.
>
>Clearly, failure to do entity substitution renders the file
>worthless.  Therefore:
>
>1.) either prohibit entities in WebCGM XML companion files;
>2.) or require that conforming WebCGM DOM implementations must
>handle entities.

I vote for 2.

>
>>[...]
>> >>   -Do we need relatedTarget on the Event interface?  I believe that
>> >>   some of the existing API offer something like this?  Is it needed,
>> >>   is it useful?
>>
>>...Dieter and I talked about this one a bit.  We don't think we need
>>relatedTarget, target should be sufficient.  The changes will be in
>>the next draft (with explanations).
>
>Fair enough.  (Just to be safe, why not directly ask vendors of "some of
>the existing API", to confirm that they're happy without it?)

I don't think this is necessary. The target will always point to the
APS under the mouse if any. The whole concept of relatedTarget does not
really apply here, since our events are all captured by the listener
of the picture.

>
>>[...]
>>LH> "WebCGM user space" suggests VDC to me.  On other interfaces
>and methods,
>>LH> haven't we decided that VDC should be avoided, because VDC require the
>>LH> context of VDC Extent?
>>Right, I know we agreed to have (0,0) at the bottom left section of
>>the illustration... but what are the (right,top) values?
>
>100%,100%.
>
>Or some Xmm, Ymm.  Question (anyone):  didn't we decide, in comments on
>earlier drafts, that this Xmm, Ymm is interpreted relative to the width-mm
>and height-mm dimensions of the VDC extent?
>
>-Lofton.
>
>
>

The coordinate system should be described as follows:

width = resulting mm width of VDC extent
height = resulting mm height of VDC extent

Origin:
lower left corner of VDC extent
coordinates at origin: 0,0
top left coordinates: width,height (or 100%,100% where applicable)

Also, the current transform of the CGM file in the viewer should be
expressed in mm (the current offset in the viewer rectangle)

Dieter




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