[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE: what URLs are allowed for GetWebCGMDocument.src
- "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.
- cgmDoc.src = ""mycurrentcgm.cgm#name(myObj,move)""
- [DW] (provided that mycurrentcgm.cgm is already loaded.
Mailing-List: contact cgmo-webcgm-help@lists.oasis-open.org; run by ezmlm
X-No-Archive: yes
List-Post: <mailto:cgmo-webcgm@lists.oasis-open.org>
List-Help: <mailto:cgmo-webcgm-help@lists.oasis-open.org>
List-Unsubscribe: <mailto:cgmo-webcgm-unsubscribe@lists.oasis-open.org>
List-Subscribe: <mailto:cgmo-webcgm-subscribe@lists.oasis-open.org>
Delivered-To: mailing list cgmo-webcgm@lists.oasis-open.org
Reply-To: <dieter@itedo.com>
From: =?us-ascii?Q?Dieter__Weidenbruck?= <dieter@itedo.com>
To: <cgmo-webcgm@lists.oasis-open.org>
Date: Thu, 16 Jun 2005 00:26:01 +0200
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
hermes.oasis-open.org
X-Spam-Status: No, hits=4.6 required=7.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
HTML_MESSAGE autolearn=no version=2.64
X-Spam-Level: ****
Subject: RE: [cgmo-webcgm] C2C/DOM -- clarifying _replace
Mailarmory-Level:
Mailarmory-Category: clean (0)
Mailarmory-Filter-Date: Wed, 15 Jun 2005 16:27:04 -0600 (MDT)
Mailarmory-Details: UmFuZG9tSVZvb4CnCeChgQej+4NeW8ks5D18xQ10Xd/9KpZ7WZvnct2VFw4e4rHQtdl6KGyP5PNN1t6KM+WsFA==
X-RCPT-TO: <lofton@rockynet.com>
X-SpamCatcher-Score: 0
X-SpamCatcher-IP: 127.0.0.1
X-SpamCatcher-1: a1fd9349c4f4c0681868df8cb4c020db
see below.
- -----Original Message-----
- From: Lofton Henderson [mailto:lofton@rockynet.com]
- Sent: Thursday, June 16, 2005 12:16 AM
- To: cgmo-webcgm@lists.oasis-open.org
- Subject: [cgmo-webcgm] C2C/DOM -- clarifying _replace
- [...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.
- [DW] we should not allow for this
- cgmDoc.src = ""#name(myObj,move)""
- but for this
- cgmDoc.src = ""mycurrentcgm.cgm#name(myObj,move)"
- [DW] (provided that mycurrentcgm.cgm is already loaded.
- 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]