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[2]: [cgmo-webcgm] Ideas about issue CL-c10

I agree that we need more information.  That won't stop me from commenting, 
however :)

See embedded...

At 02:22 PM 5/23/2006 -0400, Benoit Bezaire wrote:
>Monday, May 22, 2006, 1:17:17 PM, you wrote:
> > Thanks Benoit.
> > I have a couple of questions.  First, the simple/trivial ones...
> > what is a pane?
> > what is a tab?
>And here is my simple answer: I don't know.
> > I.e., are there standards-based definitions of these? I know 'tab'
> > from Geko-based browsers (NN7 and Firefox). I searched W3C site for
> > 'pane', and quick-look didn't give reveal any standardized thingy. I
> > ask because I assume that we would want to limit any WebCGM list of
> > such target thingies to standard-defined ones? And not suggest
> > mandatory support of browser-dependent ones (i.e., if we add
> > language like "This attribute specifies the name or portion of the
> > target window, frame, pane, tab, or other relevant presentation
> > context.")
>But on the other hand, it looks like other groups took the approach of
>going for broad wording to cover all possibilities.

That is an approach that SVG takes a fair amount.  For example, SVG allows 
any embedded raster format, but only requires PNG and JPEG.  WebCGM, on the 
other hand, requires and allows the same fixed set.  So there are legal 
SVGs that conforming SVG static viewers are not required to be able to render.

It's that issue that I was getting at, more or less -- a conformance 
criterion issue.  Assuming that 'tab' refers to NN7 tabs, do we want to 
require support for the name of a Netscape browser tab in the 3rd parameter 
of 'linkuri' in WebCGM content?

> > More substantive questions...
> > That aside, as we discussed in telecon, in 1999 even <object> was an
> > afterthought, introduced by Chris. It doesn't surprise me that we
> > don't give it the same treatment as windows and frames. So the
> > interesting questions are:
> > 1.) What level of support, as suggested by Chris, according to
> > Benoit's analysis?  Support linking to an <object>?  Example:
> > someHTMLdoc.html contains:
> > <p>...stuff...</p>
> > <object id="someObjectElement" data="someInitialCGM.cgm" ..../>
> > CGM someOtherCGM.cgm contains (conceptually) something like:
> > 1a.)
> > BegAps id="someApsId";
> > ApsAttr type="linkuri" URI="someHTMLdoc.html#someObjectElement"
> > linkTitle="" behavior="_replace";
> > or
> > 1b.)
> > BegAps id="someApsId";
> > ApsAttr type="linkuri" URI="someHTMLdoc.html" linkTitle=""
> > behavior="someObjectElement";
> > Is this the sort of generalization that we're looking at?
> > (Implementors, who could support this in the near future, if it were
> > generalized?)
>Lofton, we may be assuming too much. I agreed to the action item which
>was to analyze Chris' email. I (think) that's what he's talking about;
>but I could be wrong. I don't think vendors should look into how much
>work that is until we know for certain that we've made the correct


> > 2.) would WebCGM 2.0 want to intentionally limit itself to some
> > *subset* of the standardized set: window, frame, object, iframe?
> > (Accepting for now that the current limitation, excluding object, is
> > accidental and unintended.) Imposing a limitation would need some
> > specific requirements to back it, as Chris, SVG, and CDF seem to
> > frown on such limitations.
>Again, let's wait until we know more.

Okay.  Then what's the next step?  Should we send your analysis to Chris, 
and ask him if that's what he meant in CL-10?

> > 3.) what changes would we need to make to the document? Does it need
> > to say anything more than SVG did? Do we need to look at the
> > applicability of the keywords _replace, _self, _parent, _top,
> > _blank, <frame-target> to the target object type? (For example,
> > _replace is only defined for C-to-C links -- should it be other than
> > _self for a C-to-H <object> link? ) I'm unclear what would happen
> > with the whole behavior table in
>Same as above; we need to know that the assumptions are correct before
>talking about this.

Okay.  Let's determine that.

>I want to make an additional comment... I think we change the wording
>to please Chris and CDF, and we stop there. Nothing more.

Sounds simple and appealing.

But what worries me ... the conformance criteria (for content, but 
especially for user agents) seem to me pretty wooly in the SVG wording.  I 
have a hard time understanding what are the requirements of a conforming 
SVG UA, and what is "optional".

Anyway ... later for that ... first clarify/confirm basic intent of the 
comment (CL-c10).


> > 
> http://www.w3.org/Submission/2006/SUBM-WebCGM20-20060313/WebCGM20-IC.html#webcgm_3_1_2_2
> > Regards,
> > -Lofton.
> > At 04:05 PM 5/17/2006 -0400, Benoit Bezaire wrote:
> >>On the call today... I agreed to take an action item to look into this
> >>a bit deeper.
> >>
> >>I suspect that Chris doesn't like our wording because is it specific
> >>to HTML frames (4.01)... where the W3C CDF (Compound Document Formats)
> >>specified that compound documents must either i) use mixed
> >>namespace XML (not possible for us since we are a binary format) or
> >>ii) using the <object> tag.
> >>
> >>However, our linking sections never talk about <object>.
> >>Section says:
> >>HTML-to-CGM: 'target' attribute of a element [ref]; not applicable
> >>(n/a) for object element.
> >>
> >>Chris would probably argue that this is wrong and that it needs to
> >>work with the <object> tag.
> >>
> >>As I said, the WebCGM 2.0 spec relies heavily on references to HTML
> >>4.01, the SVG 1.2 spec does not. Our definition only talks about
> >>frame, we don't mention iframe, pane, or <object> etc...
> >>
> >>Here's the current SVG 1.2 wording:
> >>
> >>---
> >>
> >>target = '_replace' | '_self' | '_parent' | '_top' | '_blank' |
> >>"<frame-target>"
> >>
> >>This attribute should be used when there are multiple possible targets
> >>for the ending resource, such as when the parent document is a
> >>multi-frame HTML or XHTML document. This attribute specifies the name
> >>or portion of the target window, frame, pane, tab, or other relevant
> >>presentation context (e.g., an HTML or XHTML frame, iframe, or object
> >>element) into which a document is to be opened when the link is
> >>activated. The values and semantics of this attribute are the same as
> >>the WebCGM Picture Behavior values [WebCGM]:
> >>
> >><snip>
> >>
> >>"<frame-target>"
> >>  Specifies the name of the frame, pane, or other relevant presentation
> >>  context for display of the linked content. If this already exists, it
> >>  is re-used, replacing the existing content. if it does not exist, it
> >>  is created (the same as _blank, except that it now has a name). Note
> >>  that frame-target must be an XML Name [XML11].
> >>
> >>Note: The value _new is not a legal value for target (use _blank).
> >>
> >>--
> >>  Benoit   mailto:benoit@itedo.com
> >>
> >>This e-mail and any attachments are confidential and may be protected
> >>by legal privilege. If you are not the intended recipient, be aware
> >>that any disclosure, copying, distribution or use of this e-mail or
> >>any attachment is prohibited. If you have received this e-mail in
> >>error, please notify us immediately by returning it to the sender and
> >>delete this copy from your system. Thank you for your cooperation.

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