RE: [cgmo-webcgm] CL-c2 closure

[Lofton Henderson <lofton@rockynet.com>]

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: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.

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.