Fwd: WebCGM technical notes

[Lofton Henderson <lofton@rockynet.com>]

Here are the raw technical notes that Chris shared with us, about the 
WebCGM 2.0 Submission text.  These are the basis for our subsequent issue 
construction and resolution.

I'm putting them in the archive now (in the raw-notes form) so that we can 
refer to them from issues resolution documents.

>Date: Tue, 7 Mar 2006 20:37:58 +0100
>From: Chris Lilley <chris@w3.org>
>To: Lofton Henderson <lofton@rockynet.com>
>Subject: WebCGM technical notes
>
>
>Hello Lofton,
>
>  Here are my rough technical notes which I was planning to send to the wg 
> (appropriately tidied up) once it started.
>
>--
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG
requirements

contradiction between two paragraphs
http://www.oasis-open.org/committees/download.php/14243/WebCGM_20_Requirements.html#Internatio

The use of Unicode with both graphical and non-graphical text strings was allowed in WebCGM 1.0. This reqirement continues for WebCGM 2.0. There were minor errors in the specification of the sequence tail for the complete code for UTF-8 and UTF-16. This is to be corrected in WebCGM 2.0.

The internationalization of links described by RFC3987 (IRI) was discussed by the user constinuencies of WebCGM. It was determined that there is no immediate requirement for fully internationalized links per IRI. The two major constinuencies (Air Transport Association, and AeroSpace & Defence) of WebCGM apply the specification to technical illustrating. Neither of those presently allow international character sets in their linking mechanisms. Full internationalization of WebCGM, specifically including IRI, can be deferred to a future version of WebCGM (e.g., a follow-on version 2.1), and should be deferred to avoid impact the high-priority schedule requirement.

So on the one hand, characters outside ASCII can be used in the CGM and on the other hand, elements with names outside ASCII cannot be linked to. internationalisation is needed for object names, for search strings, etc. Linking may be from WebCGM to non-WebCGM. Generality is needed.

Yet the WebCFM 2.0 submission references RFC 3987, so such linking would be possible.

============

WebCGM alowed multiple pictues per file but warned against using it (deprecated in effect). WebCGM 2.0 requires hat only a single picture is used.

Can a WebCGM 2.0 picture link to a given picture in a multi-picture WebCGM 10 file?

==========



2.5.4 Character sets and fonts
Fully international text is supported in WebCGM by:
l Allowing Unicode, UTF-8 or UTF-16, to be selected in the character set designation and selection
mechanisms.

References does not describe UTF-16
not clear if non-ascii text is allowed in id


=========
3.1.1.3 Fragment Character Repertoire

WebCGM20-Profile.html#webcgm_4_3_T_14_5
Non-graphical text strings restricted to 8859-1 (model profile allows 8859-1 and UTF-8). 
Unfortunately I see that WebCGM 1.0 SR did that as well, a change from WebCGM 1.0 FE which allowed Unicode.

This means
- its much less suitable for international use
- is much less suitable as a base for other cascading profiles.
- it still needs IRI syntax (to deal with the 8859-1 rhs)

3.1.1.4 Non-ASCII characters in URIs

I think that is OK

3.1.1.5 Resolving relative URIs

The URI of the 'xcfurl' parameter of the xcfterm production in the above fragment EBNF can be absolute or relative. A relative 'xcfurl' URI is resolved relative to the WebCGM instance with which the XML Companion File is a companion — i.e. relative to the WebCGM file referenced by the base part of the URI containing the fragment — rather than relative to the file containing the URI reference (e.g., an HTML file).

That sounds odd. However it seems the xcf is loaded into the cgm viewer,using a fragment identifier that gives the URI of the xcf .... (as a char string, looks under specified).

Example in 3.1.1.5 could usefully use example.net for one of the uris,to make it clearer.

3.1.2.1 Picture selection keywords

As noted previously, the picture selection keywords are of limited utility in WebCGM 2.0, which allows only one picture per metafile. However, they are kept in the syntax for backward compatibility with WebCGM 1.0 (which allowed multi-picture metafiles), and they are a required part of the syntax if there is a picterm production present (

That covers conforming content, but says nothing about what conforming WebCGM 2.0 viewers must do if they get a URI with a fragment that has a pictseqno other than "1" and 

a) it points to a WebCGM 2.0 file.
a) it points to a WebCGM 1.0 file.

3.1.2.4.1 Enumeration of behaviors

view context is deprecated (in fact, changed, to zoom plus newHilight) need to see effect of this on SVG which uses the same mechanism.

3.1.2.6 XML Companion File

A viewer must apply the XCF before first display of the CGM. Interpreters without support for the WebCGM DOM will ignore this fragment type.

The two entences contradict each other. one says it must be suported, the other says it may be ignored.

3.1.2.7 Summary of behaviors

The behavior, as defined in section 3.1.2.2, depends upon the target content type. For HTML link targets it effectively matches HTML's "Frame Target Names", 

Seems to preclude linking or changing a specific object name,only a frame name; this contradicts CDF so needs to be resolved.
1.2 Normative references

a)
ISO/IEC 10646-1:1993, AM2:1996
Information technology - Universal multiple-octet coded character set (UCS)
- Part 1: Architecture and Basic Multilingual Plane
AMENDMENT 2: UCS Transformation Format 8 (UTF-8)

should check what CHARMOD says about referencing Unicode and UTF-8. Check its the most up to date UTF-8 spec, there have been bugfixes.

b)
REC-png
PNG (Portable Network Graphics) Specification, Version 1.0, URL:
http://www.w3.org/TR/REC-png-multi

should be
REC-png
Portable Network Graphics (PNG) Specification (Second Edition)
Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification. ISO/IEC 15948:2003 (E)
W3C Recommendation 10 November 2003
http://www.w3.org/TR/2003/REC-PNG-20031110


2.2.2 Drawing model

Color space for compositing not described, is alpha linear or not (maybe described later?)
What is the influence of grnode on compositing - grouping complexifies compositing, neds to be carefully described.

2.2.3 Overlaying a picture

This may be handled in two ways with WebCGM. First, the "TRANSPARENT" parameter of the OBJECT
tag may be used

change tag to element (the parameter is a separate element and not part of te object start tag).


2.3.2 WebCGM defined group types

para - (paragraph) an APS type to facilitate text search within graphics, in cases such as multielement, multi-line text, and other cases (e.g., polygonized text) where text search might otherwise be difficult (or impossible).

Is that a block, in terms of bidi and in terms of text to speech? Is subpara a block or an inline (span)?

2.3.4 WebCGM defined group properties

content - an attribute of the 'para' and 'subpara' APS, that can give a reasonable basis for
searching in the case of badly structured text within WebCGM instances.

Sounds like alt text, what if this is very different to the actual text? Risk of it being outdated when the CGM is revised. what does 'badly structured' mean here?

2.3.6 Hyperlinking

WebCGM supports bi-directional hyperlinking within individual WebCGM instances, between WebCGM
instances and other Web media types.

Does it really mean b-directional linking? In general the Web has a unidirectional linking model. A can link to B without altering B; B does not know that A links to it. Interlining requires a pair of unidirectiional links.

The address of the link (the first parameter of the 'linkuri') is any valid URL
according to the rules of RFC 3986.

That seems to be a change from WebCGM 1.0, which allowed a URI ora string hat could be escaped to form a URI. Although WebCGM 1.0 v2 says "The address of the link (the first parameter of the 'linkuri') is any valid URL according to the rules of RFC-2396.". hmmm

In general URL should not be used, its an undefined term. Either URI or (better) IRI should be used.

With the WebCGM 2.0 restriction of one picture per metafile, the <pict-part> is not useful, but
is maintained in the syntax for backward compatibility (with WebCGM 1.0 implementations).

Should say that its for compatibiity with 1.0 content (in 2.0 implemenations) as well.

==== got to 2.7.2  ======