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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

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


Subject: Re: fixing 3.1.2.2, picture behaviors


At 02:57 PM 3/24/01 +0100, Dieter Weidenbrueck wrote:
>[...]
>please find my comments in the attached document.

I have some comments and questions (indicated by ">>>") to Dieter's 
comments, which he embedded in the .DOC attachment to his reply:

Comments Dieter Weidenbruck:
The first column appears to be redundant for the following reason:

 >>>It was not redundant, mostly because we did not prohibit the full 
fragment syntax in H2C cases, and specifically the "_replace" behavior made 
no sense.

A link placed inside HTML will be an href. The usual form will be
Href="abc.cgm#obj1" TARGET="someTarget"

 >>>If it was a reference from an 'A' tag, yes.  But not from OBJECT 
tag.  See 3.4 ("<OBJECT DATA='xxx.cgm' ...>").

This link will be executed by the non-CGM environment, i.e. the HTML 
browser. Hence the HTML rules apply. So the HTML browser will only react to 
target keywords if the target has been specified using TARGET="…".
The HTML browser will NOT react to any target that is embedded inside a 
fragment because it is not its job to examine the URL fragment.

 >>>So are these picture behaviors allowed on H2C fragments, or are they 
not allowed?  If they are allowed, then it implies that the viewer must 
somehow communicate with the browser about it.  Really, is this any 
different from a C2C case, that occurs at the end of a H2C2C chain (where 
the H set up the initial frameset?)?

The URL including the fragment will be passed on to the CGM viewer which 
will already exist at that point in time.
So basically the content of row 1 can be deleted and the behavior can be 
left up to the HTML specification.

 >>>You mean *column* 1?

With regard to WebCGM a hint would be useful, like:
When addressing a CGM from outside the CGM environment using an href, the 
picture behavior keyword will be ignored. In these cases use the TARGET="…" 
expression defined for the href instead.

 >>>Does everyone agree that it this what we intended originally?  (I can 
live with this as a clarification, if "yes").

Other things to look out for:
We continue to have a redundancy because there are two places where one can 
specify a target:
-       the picture behavior in the fragment
-       the third (target) parameter of the linkURI

 >>>Does anyone recall the reason for this?

Suggestions:
Once we go to a 1-picture WebCGM the full fragment will no longer be needed 
because the picID and picName will no longer be used. So from there on only 
the behavior would lead to a long fragment.

 >>>You mean, "only the *object* behavior"?

To avoid this and to harmonize we should in general specify the target in 
the third param of the linkURI, i.e. separate from the fragment. We can 
still leave the current fragment syntax in place, however, there is so much 
confusion already that there will be a change in viewer behavior as soon as 
we implement the recommendations above.

 >>>I don't understand.  Do you mean implement, "ignore picture behavior 
parts of fragment in H2C" links?

If we use the third param for all targets, no matter whether within or 
outside of CGM we are consistent with the href syntax.

 >>>As I read 3.2.2.3, the 3rd param is *required* for non-CGM.  But 
paragraph 5 of 3.2.2.3 suggests says that the fragment is used for CGM 
targets, and in fact a Release 2 editorial correction is changing "should 
normally" to "shall".  It is clear that we did not intend 3rd parameter to 
be used in these cases, regardless of what we think now.

If we continue to allow for both ways we need to clarify the wording a bit.

 >>>Prohibiting "#" fragment and requiring 3rd parameter seems like a 
significant functional change.  I don't think we can consider it for 
Release 2 of WebCGM 1.0.  (On the other hand, it might be possible to allow 
3rd parameter form, and even deprecate the "#" fragment, but making a 
different editorial fix to last sentence of 5th pgph 3.2.2.3, than the one 
currently specified.).

 >>>I guess my preference is clarify but not change, even if we would all 
prefer always the 3rd parameter form -- the current stuff works and does 
not invalidate existing implementations.

 >>>Kevin and Don also responded, respectively:

Kevin:  "I believe our goal, to be consistent with the HTML href element, 
should be
to make the BEHAVIOR attribute of the LINKURI element be the primary
mechanism for implementing this functionality."

 >>>So you are recommending to modify 3.2.2.3, 5th pgh, to allow the 3rd 
parameter form for CGM targets?  Now in WebCGM 1.0?

Don:  "I agree with Dieter that HTML to CGM is redundant. In fact I don't 
believe
we can define that behavior since it is the Browser that would initiate that
action therefore behavior is under control of the Browser."

 >>>Again, I don't see how this differs from some of the picture behavior 
options in the case of the C2C part of a H2C2C sequence, where the original 
H sets up the frameset.

-Lofton.




*******************
Lofton Henderson
1919 Fourteenth St., #604
Boulder, CO   80302

Phone:  303-449-8728
Email:  lofton@rockynet.com
*******************



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


Powered by eList eXpress LLC