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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

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


Subject: scope of WebCGM conformance


All --

Here is the last issue of the current set which I have dragged out of a 
detailed (TR extraction) reading of WebCGM 1.0.  This one bears on what 
can/cannot be tested in WebCGM 1.0.

A fundamental issue about conformance in WebCGM 1.0...

CLARIFICATION/ISSUE.  3.1.2.2, Enumerated picture behavior keywords and 
Frame Target Names.   What is the context in which the frame name, and 
indeed the frame-related behaviors (keyword values), are evaluated?  Since 
clearly, the fragment must be part of a URI pointing to (or into) a WebCGM 
instance, then the content could occur in HTML-to-CGM links, or in 
CGM-to-CGM links.  The frame concept is well defined in the first.  But 
what about the second?  As these behaviors and frame names are explained in 
the spec, their use in a CGM-to-CGM link implies that the WebCGM viewer 
*must* be running in a browser environment, and there is implicitly an HTML 
parent document somewhere back in the chain of links.

Conclusion:  As the spec is currently written, full WebCGM functionality is 
only defined in the context of HTML documents, and so full WebCGM 
conformance is only testable in the context of HTML documents and a 
browser.  I.e., only a plugin or activeX control could be tested for full 
WebCGM 1.0 conformance.  I think this architectural context has been 
implicit from the start of the WebCGM effort, but curiously, it never is 
stated explicitly in the spec.

Alternatives:

Alt.1 -- as Conclusion, above.  (Solution.  State it explicitly in the spec).

Alt.2 --  we didn't intend this consequence.  It could be mitigated by 
defining a small number (2-3) conformance classes matched to viewer classes 
(e.g., standalone viewer, or XML-companion viewer, or ...), and within each 
class for each "problematic" WebCGM functionality (e.g., frame-related 
picture behaviors), define a default viewer behavior for that functionality 
for that class.

Alt.3 -- similar to Alt.2, but define which functionalities make sense for 
which viewer classes, and define conformance of those viewer classes in 
terms of the appropriate subset of WebCGM functionality for that class.

Alt.1 is simplest and quickest.  I think it is what we believed to be the 
scope of WebCGM 1.0, but never said so explicitly in the spec.

Alt.2/3 are more comprehensive and much more work (SVG has had to deal with 
this issue, as it is positioned to be all kinds of things to everyone in 
most conceivable Web environments.  See the wording in Appendix G of SVG, 
where the requirements of the viewer are framed in terms of the 
capabilities of the environment in which it is operating).

Thoughts?

-Lofton.




*******************
Lofton Henderson
1919 Fourteenth St., #604
Boulder, CO   80302

Phone:  303-449-8728
Email:  lofton@rockynet.com
*******************



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


Powered by eList eXpress LLC