[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