RE: [cgmo-webcgm] CL-c2 closure

At 06:38 PM 4/19/2006 +0200, Dieter  Weidenbrück wrote:

Lofton,

 

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?

Cheers,

-Lofton.

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.