Lofton,
you basically answered all my questions, I just wanted this
to be clarified for everybody at some place.
We are in agreement.
Dieter
From: Lofton Henderson
[mailto:]
Sent: Wednesday, April 19, 2006 6:25
PM
To: ;
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:]
Sent: Wednesday, April 19, 2006 5:30 PM
To: ;
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.
Agreed.
>
> (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 3.1.2.4 [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 3.2.2.3, that
it now says "The destination of a link is specified by a Uniform Resource
Identifier, or URI. See section 3.1.1.4 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
3.1.2.4-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.
-Lofton.
