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: [cgmo-webcgm] CL-c2 closure

At 06:38 PM 4/19/2006 +0200, Dieter  Weidenbrück wrote:
you basically answered all my questions, I just wanted this to be clarified for everybody at some place.

It was a good discussion.  It has pointed out to me, yet again, how difficult it is to write absolutely bomb-proof prose in a spec.  I can now see some small chinks in the wording, that could be misread by someone who didn't know "what we meant..." (or at least what the spec author meant).  That is why it is so valuable to write test suites, especially to have non-spec-authors write them!

We are in agreement.

How could two such smart fellows not agree?


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Wednesday, April 19, 2006 6:25 PM
To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] CL-c2 closure
At 05:40 PM 4/19/2006 +0200, Dieter  Weidenbrück wrote:
Lofton, see inline
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Wednesday, April 19, 2006 5:30 PM
To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] CL-c2 closure
Two points...

At 03:41 PM 4/19/2006 +0200, Dieter  Weidenbrück wrote:
> I'm not sure that it's necessary.  I think the mapping
> specification -- what 2.0 viewers must do with legacy
> occurrence of the 1.0 behavior 'view_context' -- I would
> think that is sufficient.  But I don't feel strongly if
> someone wants to supply some clarifying wording.
I was thinking of the "outside" world, like HTML etc.
There is at least no current mapping of 2.0 behaviors to 1.0 files.
It is unnecessary to "map". IMO, it suffices to say:  2.0 viewers shall treat 2.0 object behaviors, applied to 1.0 files, according to this 2.0 specification.  (Of course 2.0 behaviors cannot appear within fragments within the content of 1.0 files, nor can we say anything about how 1.0 viewers shall behave if they run into 2.0 behaviors -- that would mean retroactively changing the conformance requirements of 1.0, which is generally frowned upon.)
 This is one way how to do it, to specify the viewer behavior in this way. We should do this.

> (Of course, if the 'view_context' appears within a
> ProfileEd:2.0 metafile, that is an erroneous metafile and
> WebCGM does not specify the viewer error
> reaction.)
no, I disagree, this is not always the case.
What is "not always the case"?  That it's an illegal 2.0 metafile if it contains 'view_content' in an internal fragment?  That seems unambiguous according the spec...
Reading [1], and following the link to 7.2.2,

"Deprecated features must not be present in conforming 2.0 content, but must be supported by conforming 2.0 viewers that support conforming 1.0 content.

The following requirement supplements the general defined requirements for deprecated features, for the specific case of the three deprecated object behaviors: WebCGM 2.0 viewers shall support these behaviors, and such support shall be according to the defined mapping onto the 2.0 set of object behaviors. Note. This specification is made because legacy occurrences of these behaviors can originate in non-CGM content types, and can occur independently of the versioning mechanism of WebCGM content."


[1] http://www.w3.org/Submission/2006/SUBM-WebCGM20-20060313/WebCGM20-IC.html#webcgm_3_1_2_4

Therefore, I'm saying that it is unnecessary (actually inappropriate) to specify what a viewer does, if it finds 'view_context' in a fragment that is contained within the content of a ProfileEd:2.0 metafile.  It is an illegal metafile.
If I would follow this, it would mean that a WebCGM 2.0 file could never point to a WebCGM 1.0 file using 1.0 behavior.

Correct.  And the specification has said this ever since we invented the 2.0 object behaviors, and wrote the mapping rules for the *deprecated* 1.0 behaviors.  (Recall, I tried hard to get people to look at and review the conformance stuff, like the 7.2.2 deprecated section -- no one ever brought this up before, since it was written last summer.)  Note also that 'view_context' doesn't appear in the normative 2.0 EBNF in 3.1.1.

QUESTION.  Why would you want a 2.0 file to point to a 1.0 file using 'highlight', 'highlight_all', or 'view_context'?

In the first two cases, there is an exact 2.0 equivalent.  In the 'view_context' case ... well, the exact 1.0 semantics are not available any more.  It can only be approximated by zoom+newHighlight (actually, with DOM.  This was the gist of your victory on the issue about whether a 2.0 viewer should map 'view_context' (changing the behavior of links coming from legacy sources), or should honor the 1.0 semantics (leaving legacy links unchanged).

(Btw, my assumption:  Since it is a 2.0 file, presumably it is a 2.0 viewer that is interpreting and executing the link.)

So it is legal to specify any valid URI in a linkuri residing inside a WebCGM 2.0 file,

"legal" and "valid" referred in 1.0 to the rules of IRI and such specifications, i.e., to the legal-character rules.  That statement does not supersede other rules, e.g., content rules of 1.0 and 2.0.  That is one reason, in the normative, that it now says "The destination of a link is specified by a Uniform Resource Identifier, or URI. See section for discussion of valid values of this parameter."  (Okay, that latter reference is specifically to the URI-character-legal subsection of 3.1.1, and I think it should also be to 3.1.1 in general).

(Or, are you saying that all of the fragment rules of section 3.1.1 don't apply to fragments on CGM-CGM links within metafiles?  I.e., are you really suggesting that *any* string of IRI legal junk is valid, after the #, in a CGM-CGM link that starts in a 'linkuri'?)

why not specify a URI that is legal in a 1.0 context, pointing to a 1.0 file?

Because we are trying to get rid of it ('view_context'). That is the meaning of "deprecation".  According to what you are recommending, then the old three 1.0 object behaviors are perfectly valid in a 2.0 file, and from a conformance standpoint, there is absolutely no difference from the twelve new behaviors.

Should we allow for 2.0 compliant URIs only in cases where the linkURI parameter points to non-2.0 CGM files?

I don't understand this question.

What about a cascaded profile that defines own keywords or even a (partially) different fragment, which all would be illegal in a WebCGM 2.0 context?

That profile is extending the WebCGM 2.0 profile.  See 7.4.2.  It is not a valid WebCGM 2.0 metafile, but it is allowed and it would be a valid Cascaded Profile.

As soon as the CGM to CGM linkuri points to a different file,
view_context may appear, since this may be a 1.0 file. Same as
any legal URI.

If 'view_context' object behavior is within a fragment in HTML, or within a fragment in a ProfileEd:1.0 metafile, then yes, we should say what 2.0 viewers do ("they map it", and we do say that now in
I think, you misunderstood my sentence above. I was talking about a URI residing in a linkURI attribute inside a CGM file, pointing to a different CGM file.

That is also what I am talking about.  And my point is:  if it is a 2.0 file, then 'view_context' shall not appear within the file.  This is what the specification says. 

Aside/observation.  IMO, we have spent far more time on object behaviors than any other single technical topic in WebCGM, for several years now!  We should not reopen any reasonably closed behaviors issues.  Chris asks some questions that are not answered by the spec.  We should clarify them.  Other questions are answered by the spec.  We should leave them alone.


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