OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] CL-c2 closure


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. 

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]