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.
>
> (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.
So it is legal to specify any valid URI
in a linkuri residing inside a WebCGM 2.0
file,
why not specify a URI that is legal in a
1.0 context, pointing to a 1.0 file? Should we allow for 2.0 compliant URIs
only in cases where the linkURI parameter points to non-2.0 CGM files? 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?
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.
Dieter
-Lofton.
-Lofton.
