[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] CL-c2 closure
At 05:40 PM 4/19/2006 +0200, Dieter Weidenbrück wrote:
From: Lofton Henderson [mailto:email@example.com]
Sent: Wednesday, April 19, 2006 6:25 PM
To: firstname.lastname@example.org; email@example.com
Subject: RE: [cgmo-webcgm] CL-c2 closure
Lofton, see inline
- From: Lofton Henderson [mailto:firstname.lastname@example.org]
- Sent: Wednesday, April 19, 2006 5:30 PM
- To: email@example.com; firstname.lastname@example.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 188.8.131.52 , 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."
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 184.108.40.206, that it now says "The destination of a link is specified by a Uniform Resource Identifier, or URI. See section 220.127.116.11 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 18.104.22.168-plus-7.2.2).
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.