cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: C2C/DOM -- clarifying _replace
- From: Lofton Henderson <lofton@rockynet.com>
- To: <cgmo-webcgm@lists.oasis-open.org>
- Date: Wed, 15 Jun 2005 16:15:34 -0600
[...2nd of two issues about implementing the _replace
clarification...]
Feedback welcome (esp. implementors)...
As a first cut at implementing the no-reload decision for _replace, I
took Benoit's suggested words and applied them to _replace in the
definition list of 3.1.2.2 and to the _replace cell of the table.
Which resulted in...
Old text
-----
The viewer shall replace the
current picture by the designated picture in the same rectangular area in
the same frame or window as the picture which refers to this target. This
is the default behavior for CGM-to-CGM links.
New text
-----
The viewer shall replace the
current CGM picture by the designated CGM picture in the same rectangular
area in the same frame as the picture which refers to this target. If the
ending resource (CGM) is the same as the linking resource, the viewer
does not reload the resource. This is the default behavior for
CGM-to-CGM links.
[_replace in the definition list of 3.1.2.2 has this additional sentence
at the end, "Applicable only to CGM-to-CGM links (i.e., this is not
defined in HTML 4.01), this is the default behavior for such
links."]
Then I looked again at Dieter's mail, which raised two questions (see
after):
At 05:18 PM 6/14/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?=
wrote:
1. LinkURIs
CGM to CGM linkURIs like
#name(myObj,move)
simple navigation to another object
#xcf(myXCF.xml)
load and apply this companion file
2. DOM calls
(assume a cgm is loaded and
displayed)
cgmDoc.src =
""#name(myObj,move)"
cgmDoc.src =
""#xcf(myXCF.xml)"
This is especially important to
be able to load XML companion files in a sequence, e.g.
- myScreentips.xml
- myLinks.xml
-
myConfiguration.xml
Suggestion:
If a picture behavior is
explicitely stated, it must be used
If no picture behavior is
stated, and the nature of the link doesn't require a reload of the file,
don't use a picture behavior.
Questions:
1.) [...see previous message...]
2.) Benoit's proposed wording, like my proposal, only covers
CGM-to-CGM links, not script-based DOM calls. Because that is what
this table dealt with since 1999. I'm a little reluctant to weight
it down with normative DOM-related details (but don't mind having a
reference to additional discussion). But that leaves a question,
where to clarify about DOM calls, like Dieter's #2 above.
I think it ought to be clarified, because that scenario hadn't occurred
to me, and I hadn't yet noticed the text in 5.7.2 GetWebCGMDocument,
description of 'src' attribute:
- "The URI of the current document. On setting, the new document
pointed to by the URI is loaded by the user agent. The user agent must
fully parse the fragment identifier (if any) in the URI and execute the
indicated behavior.
So do we intend to allow *any* legal fragment there, just as if it
occurred in the body of the CGM (which presumably is loaded through the
OBJECT tag in HTML document that contains the script)? I.e., the
following example in scope? Assuming myCGM.cgm is the currently
loaded CGM document, then this is okay...
cgmdoc.src =
""http://example.org/webcgm/engine_top.cgm#pictseqno(1,_blank).id(cyl-hd-t,highlight)"
(Pardon if this is an obtuse question, but I haven't done much
programming of the activeX interface or plug-in interface ilk, so I don't
know if this is scary or a no brainer.)
Btw, should we have a test case where the "src = "..."" contains
fragments?
-Lofton.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]