Next in thread →
Next in month →
RE: [cgmo-webcgm] Issue: 5.7.3 Interface WebCGMMetafile - attribute src
At 11:36 AM 4/19/2006 +0200, Dieter Weidenbrück wrote: Lofton, we are not far from each other, I think. We agree that at least one para needs clarification. We also agree that a full fragment is needed under certain circumstances. A full fragment may or may not contain a picBehavior, there is no distinction between a full fragment and a "very full fragment" or such. This all is quite simple and could easily be changed. My additional point is this one: For a long time we will live with mixed 1.0 and 2.0 environments. Hence we need to take care of all situations where this may result in uncertaincies IMO. I agree. Example: Assume, the following appears on an HTML page: <a href=""myfile.cgm#pictseqno(2,_blank).id(myObjId)" >something </a> if myfile.cgm is a 1.0 file: One could argue that the viewer has to replace the content of the current HTML page (no target specified), stay empty, create a new window, and display the cgm there. In reality, most viewers will simply ignore the _blank behavior. However, it is legal. It is? According to WebCGM 1.0 text [1]: [1] http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2 [[[ "In the case that a link is HTML to CGM, the picture behavior should not be included in any fragment specification. Rather, the effect should be achieved with HTML TARGET attribute on the link specification in the HTML, per the specifications in the HTML 4.0 Recommendation. CGM viewers shall ignore picture behavior specifications in URI fragments which are part of links from non-CGM content." ]]] Okay, so it is legal in the sense that we say "should not" instead of "shall not" (because we think that a CGM profile cannot put normative requirements on HTML content). But this wording is essentially unchanged in 2.0 [2]: [2] http://www.w3.org/Submission/2006/SUBM-WebCGM20-20060313/WebCGM20-IC.html#webcgm_3_1_2_2 if myfile.cgm is a 2.0 file: _blank SHOULD NOT be there, and the viewer must ignore it. What have I missed? I don't see any difference between the 1.0 and 2.0 profile specification, for this particular case. (And see below about 1.0 files versus 2.0 files as link targets.) similar mixed cases occur when specifying object behaviors for archives full of 1.0 AND 2.0 files. I think that the behavior of an HTML link ought to be the same independent of whether the target CGM is 1.0 or 2.0. It *might* depend on whether the target viewer is 1.0 or 2.0 (and it does depend in the case of 'view_context'). So my point is to clearly require that 2.0 viewers ignore picBehaviors where not appropriate to facilitate working in mixed environments. This aspect was not discussed at the time we wrote all this. It is a subtle difference, however, it is cleaner IMO. I agree in principle. But I'm confused about some of your examples and the details. (E.g., the particular chosen example of an HTML link to CGM content already meets your criteria, and that specification is unchanged between the 1.0 profile and the 2.0 profile specs). -Lofton. > -----Original Message----- > From: Lofton Henderson [mailto:] > Sent: Monday, April 17, 2006 5:22 PM > To: ; > Subject: RE: [cgmo-webcgm] Issue: 5.7.3 Interface > WebCGMMetafile - attribute src > > At 10:33 PM 4/14/2006 +0200, Dieter Weidenbrück wrote: > >Dave, > > > >sorry, you are correct of course, I was a bit too short in my answer. > > > >The para should be changed, > > Yes, clarified at least. > > >like all places where we try to prohibit the picterm. It becomes too > >complicated IMO. > > Hmmm... I'm not sure that I agree, or maybe I don't > understand what you're proposing. Let me go through the background... > > Here is the 1.0 text, in 3.1.2.2: "For HTML-to-CGM links, > the picture behavior should not be included in any fragment > specification. Rather, the effect should be achieved with > HTML TARGET attribute on the link specification in the HTML, > as specified in the HTML 4.01 Specification. CGM viewers > shall ignore picture behavior specifications in URI fragments > which are part of links from non-CGM content." > > Notice the use of "should not" instead of MUST NOT. The > reason: we thought that the WebCGM standard cannot put > binding conformance requirements on HTML content. > > Does the same to the .src attribute in DOM-script content, > even though it becomes an attribute in a CGM DOM transaction? > (I don't know -- I'm asking.) > > > >Facts: > >- we have the requirement to use a full fragment in certain cases > >- hence this full fragment will contain a picTerm > >- this picTerm may or may not contain a picBehavior > > Right, these are valid full-fragment examples: > > pictseqno(2).id(myObjId,zoom) > pictid(myPicId).id(myObjId,zoom) > > > >So in all cases like this one here, we would need a phrase like > > > >"If a URI fragment is present, and if it contains the so > called picTerm > >portion of the fragment, it must not contain a behavior term, and the > >default behavior assumed for picTerms without a spelled out > behavior will > >be ignored as well. ..." > > > >My suggestion was that now that we know that picBehavior > doesn't make sense > >in certain places, we could simply add a phrase there like > > > >"If a URI fragment is present containing a picBehavior, the > picBehavior > >will be ignored." > > That might be a subtle change here from what the spec. currently > attempts. For HTML content, it says how it should be > properly formed, and > tells the viewer what to do if not proper. For CGM content, > it usually > tries to put conformance rules on the CGM content, and NOT > specify how > viewers should handle illegal CGM content. (In general, > WebCGM does not > specify error reactions to invalid content, it only specified correct > reactions to valid content.) > > Bottom line... I guess I don't have a problem, in these mixed > and confusing > cases (.src in script content as a CGM DOM attribute) adding > the directive > to "ignore". And it isn't clear whether we can or cannot put > conformance > constraints (MUST) on the .src attribute itself. > > > >Just looking for simpler words. > > > >Also, we can test, whether a viewer will successfully ignore > a picBehavior > >in these places. We can not test whether an HTML page > contains a compliant > >URL fragment. > > Right. And the HTML bit in 3.1.2.2 has been written that way > since 1.0. > > I guess I don't have a problem with the suggestion to put an ignore > directive in these places. I would still like to see us keep > the MUST > NOT conformance imperative wherever we can, for example in the first > parameter of the 'linkuri' ApsAttr (3.2.2.3). > > -Lofton. > > > > > -----Original Message----- > > > From: Cruikshank, David W [mailto:] > > > Sent: Friday, April 14, 2006 10:25 PM > > > To: ; > > > Subject: RE: [cgmo-webcgm] Issue: 5.7.3 Interface > > > WebCGMMetafile - attribute src > > > > > > Dieter, > > > > > > I don't think that was the question.... > > > > > > The paragraph quoted has a sentence: > > > 'If a URI fragment is present, it must not contain a picture > > > behavior term, following the "Picture behaviors" rule for > > > links to CGM content from non-CGM content.' > > > It is not a sentence that parses very well (i.e., remove the > > > clause between the commas and it isn't even a sentence). Are > > > there too many commas or some left over words from some time > > > in the past. > > > > > > I think the question you are addressing is whether the > > > requirement (not containing a picture behaviior term) is > > > correct. That's a different issue. > > > > > > Thx...Dave > > > > > > > > > > > > Technical Fellow - Graphics/Digital Data Interchange Boeing > > > Commercial Airplane 206.544.3560, fax 206.662.3734 <-- NEW > > > NUMBERS > > > > > > -----Original Message----- > > > From: Dieter Weidenbrück [mailto:] > > > Sent: Friday, April 14, 2006 12:58 PM > > > To: Galt, Stuart A; > > > Subject: RE: [cgmo-webcgm] Issue: 5.7.3 Interface > > > WebCGMMetafile - attribute src > > > > > > In those cases where the picBehavior doesn't make sense, > > > shouldn't we rather simply say that this part is ignored by > > > the recipient? > > > > > > Example: > > > an <a href="...>" element on an HTML page contains a > > > picBehavior where it shouldn't. How do we test for compliance? > > > The test can only be that the viewer does whatever is the > > > intended behavior, which is to ignore whatever is there. > > > This would also cover the cases where picTerm is required > > > because a full fragment is required. > > > > > > Thoughts? > > > > > > Dieter > > > > > > > -----Original Message----- > > > > From: Galt, Stuart A [mailto:] > > > > Sent: Friday, April 14, 2006 9:45 PM > > > > To: > > > > Subject: [cgmo-webcgm] Issue: 5.7.3 Interface WebCGMMetafile > > > > - attribute src > > > > > > > > Hello, > > > > > > > > I am having a bit of difficulty parsing the following paragraph: > > > > > > > > > > > > src of type WebCGMString > > > > 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. If a > > > URI fragment > > > > <WebCGM20-IC.html> is present, it must not contain a > > > picture behavior > > > > term, following the "Picture behaviors" > > > > <WebCGM20-IC.html> rule for links to CGM content from non-CGM > > > > content. If the CGM resource pointed to by the URI is > > > currently loaded > > > > for the object, the user agent shall not reload the CGM > (similar to > > > > the specification of a same-CGM URI for the _replace behavior > > > > <WebCGM20-IC.html> on a CGM-to-CGM link.) Upon retrieval, if no > > > > WebCGM document is open in the viewer, an empty string <> is > > > > returned. > > > > > > > > Specifically: > > > > If a URI fragment is present, it must not contain a picture > > > behavior > > > > term, following the "Picture behaviors" rule for links to > > > CGM content > > > > from non-CGM content. > > > > > > > > I am assuming that the URI must not contain any embeded > > > behavior, that > > > > the fact that it must follow the behavior rules is > leftover from a > > > > previous edit session? > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Stuart Galt > > > > SGML Resource Group > > > > > > > > (206) 544-3656 > > > > > > > > > > > > > > > > > > > > > > > > >
Next in thread →
Next in month →