This presents discussion and proposed resolution of those preliminiary Chris Lilley technical comments that have been discussed and decided by the WebCGM TC. (Note: the Kavi mail archive has made a mess of that reference, by embedding the two .TXT attachments in-line in the email body.)
Below, Chris Lilley's original text is in italics. Blockquoted sections delimited by"[[[...]]]" represent text from WebCGM 2.0 spec (and 2.0 Requirements spec).
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 textstrings was allowed in WebCGM 1.0. This requirement continues for WebCGM2.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 WebCGM2.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.
This one caused us some confusion. We suspect that Chris may have misread the intent. The intent of the WebCGM constituency was to support reasonable internationalization of object names and links, but reflected some worry (without having any specific examples) of getting entangled in CharMod issues that might seriously delay the schedule, if they did not contribute to satisfaction of the mainline requirements of the WebCGM constituency.
The first quoted paragraph is correct -- utf8 & utf16 are allowed anywhere that S and SF data are allowed (if properly declared etc). The flexibility in names is there.
Add a reference to a note from the requirements document to clarify the meaning.
WebCGM alowed multiple pictues per file but warned against using it (deprecated in effect). WebCGM 2.0 requires that only a single picture isused. Can a WebCGM 2.0 picture link to a given picture in a multi-pictureWebCGM 10 file?
This is a good point, that we should clarify. There is no problem with WebCGM 2.0 content rule of 1 picture per metafile. The problem arises with fragments:
Remove the "pictseqno ::= 1" line, and restore to 3.1.2.1 the WebCGM 1.0 rules for what to do with an out-of-range pictseqno.
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.]
#a is purely editorial. #b, it is absolutely our intent that non-ASCII is allowed in apsid parameter -- see last sentence of 3.2.1.
Conclusion: no issue. (See however CL-c1, discussion about scope of non-ASCII support.)
Implement editorial change to satisfy Chris Lilley comment.
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
We don't understand this comment. We believe that 2.0 (like 1.0) allows Latin1, or utf8, or utf16 in SF, but only one choice per metafile, and it must be declared in the BegMet element. Perhaps we are missing some ambiguity in the wording? See PPF, T.14.5.
Pursue clarification with Chris.
3.1.1.4 Non-ASCII characters in URIs
I think that is OK
Great! We got it right. (This should also be the subject of a clarifying erratum for 1.0, as it unifies two disparate ways that 1.0 was interpreted.)
Do nothing further for WebCGM 2.0. Add to erratum list for WebCGM 1.0.
[[[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.
We're unsure what is the problem. Chris seems to think it is okay, as illustrated by the example (plus suggests some improvement to the latter). But seems to think the wording is odd. Anyone see what the problem is?
Pursue clarification with Chris.
[[[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
See CL-c2.
See CL-c2
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.
First, the *default* is changed to zoom+newHighlight. Second, the 2.0 mapping rule for viewers is "map view_context to zoom+newHighlight". We're not sure about the benefit of constraining WebCGM 2.0 by the 1.0 rules, because the latter were adopted into SVG (if indeed they were) -- the constituencies (and requirements) are very different, and the 2.0 set of atomic rules have been well-discussed based on 1.0 experience.
Follow-up email discussion: view context deprecated
Pursue clarification with Chris on whether we need to close a gap here with SVG.
[[[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 sentences contradict each other. one says it must be suported ,the other says it may be ignored.
This is editorial, right? What we meant to say is "A viewer with DOM support must apply the XCF before first display of the CGM. Interpreters without support for the WebCGM DOM will ignore this fragment type."
Fix the wording
[[[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 "FrameTarget Names", ]]]
Seems to preclude linking or changing a specific object name, only a frame name; this contradicts CDF so needs to be resolved.
This comment caused some confusion. 3.1.2.7 is a summary (informative) and pointers to the widely scattered rules that determine all of this, and those rules all are 1.0 stuff. (The list of obj. behaviors has changed, but not how all the bits fit together.) The particular quoted comment is a footnote on the table, which footnote applies specifically to 3.1.2.2 (pic. behaviors). Perhaps Chris missed this point. Anyway, this table summarizes 1.0 behaviors and syntax that are carried forward unchanged into 2.0 -- there is no 2.0 requirement to alter this (legacy) 1.0 stuff for 2.0. We are unsure about the implications of changing it to align it all with CDF -- it predates CDF by 6 years.
Everyone agrees that the table is confusing and can be improved.
Reformat table into narrative text explaining that this is informative and is a summary of where to find normative rules.
Start Proposal
3.1.2.7 Summary of behaviors
The following is an informative summary and is intended to provide references to where the normative picture and object behaviors are defined.
For links that are specified with a URI and have CGM as a target object behaviors may be specified as described in section 3.1.2.4
For HTML to CGM links the picture behavior is defined by the HTML target attribute of the <A> tag [ref 3.1.2.2]. The picBehavior will be ignored [ref 3.1.1.2].
For CGM to HTML links the picture behavior is to use the optional third parameter of the linkuri application structure [ref 3.2.2.3]. Valid values of this parameter are described in 3.1.1.4.
For CGM to CGM links the preferred method of specifying picture behavior is to use the optional third parameter of the linkuri application structure [ref 3.2.2.3]. Encoding the picture behavior in the first parameter of the linkuri application structure is discouraged [ref 3.2.2.3].
For DOM script to CGM links the src attribute of the WebCGMMetafile interface specifies the URI of the image. Specifiy behavior as part of the URI is prohibited [ref 5.7.3].
XCF to CGM links are prohibited. However, an XCF may edit an existing linkuri application structure [ref 3.2.2.3].
End Proposal
Need to clarify with Chris the requirement for alignment with CDF. BB has taken an action to research the CDF parts.
[[[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 bug fixes.
Seems straightforward updating of reference. LH has taken action item to look at CharMod as suggested.
Update reference as needed.
[[[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
Seems straightforward updating of reference.
Update reference as needed.
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, needs to be carefully described.
The WebCGM text is somewhat underspecified here. There are a couple of things that need to be looked at: Esc 45 (alpha transparency, registered), sRBG (registered), and RGBA/sRGBA (registered). Esc45 says "applies to subsequent primtives". So far, there is *nothing* in CGM or WebCGM that hints at a drawing model different from "order of primitives", i.e., nothing that says to treat drawing primitives within an APS any differently than those outside. Alpha is not a property of an APS, it is a primitive-level property. This applies to grnode APSs, just like any other APS. WebCGM has no notion of "group opacity", like SVG. This is all 1.0 functionality, and the addition of grnode doesn't impact that.
BB to research and propose the answers about color space for compositing, and whether alpha is linear (we think it is).
Color and alpha transparency (other than 0.0 and 1.0) are not primary high-requirement functionalities of the WebCGM constituencies, and so they may have sat underspecified for six years.
BB has taken an action to put together a proprosal to answer the questions from Chris.
[[[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).
Agreed. It's editorial. Fix it.
Implement the editorial change.
[[[2.3.2 WebCGM defined group types
para - (paragraph) an APS type to facilitate text search within graphics, in cases such as multi-element, 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)?
All of this was purposely underspecified in 1.0, with the idea that requirements would be refined and it would be further specified in future versions. Such a requirement did *not* make it into the priority requirements for 2.0. It was discussed, and explicitly deferred again (until after the high-priority DOM and XCF were done). Note that what's inside para and subpara could in fact not even be text primitives -- it could be polybeziers or even raster bit blts.
Therefore, preliminary feeling of the TC is that questions such as 'bidi block' or 'text to speech' mapping are unanswerable, until appropriate requirements and more precise specification are added to WebCGM. To overspecify these questions (in 2.0) now could interfere with the anticipated elaboration of this functionality in a WebCGM 2.1, for example. LH is researching it a bit more.
Currently unresolved. Upcoming discussion in a telecon.
[[[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?
Once again, all of this was purposely underspecified in 1.0, see CL-d5. It is fine if it's very different from actual text. These things were put into 1.0 as (underspecified) hooks for future standardization, or use by cascaded profiles, or ... Once again, note that it might not even be RestText elements inside the APS -- could be raster or geometric primitives. In fact, the whole picture could be a raster image, and this stuff could occur in "overlay mode"(as opposed to embedded mode).
("badly structured" might mean something like text that was letter-by-letter per RestText element, in an order very different from reading order.)
Currently unresolved. Upcoming discussion in a telecon. See CL-d5
[[[2.3.6 Hyperlinking
WebCGM supports bi-directional hyperlinking within individual WebCGMinstances, between WebCGM instances and other Web media types. ]]]
Does it really mean b-directional linking? In general the Web has aunidirectional 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.
No, this needs editorial clarification. It was only meant to express that you can link CGM-to-other-stuff, and you can link other-stuff-to-CGM.
Clarify wording to explain this.
[[[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 or a string that 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
This (informative) wording should have been changed and was missed. There is a similar sentence in 3.2.2.3 (normative) which *was* changed, simultaneous with fixing 3.1.1.4 (non-ASCII in URIs). Those changes were made together, to remove ambiguity that existed in 1.0, and clarify for 2.0. (They are planned to be an erratum for 1.0, to validate the two different, equally correct readings of 1.0).
Fix it as just described.
In general URL should not be used, its an undefined term. Either URI or (better) IRI should be used.
Right, this is an editorial fix that should be made (and search whole document for "URL").
Fix it as just described.
[[[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.
Yes, it should say that. The issue is bigger, however -- see CL-c2 and CL-c7.
Fix it as just described.