[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: preliminary assessment of CL comments
cl-c-summ.txt: CL-c1 thru CL-c9, from "..-comments.txt" cl-d-summ.txt: CL-d1 thru CL-d10, from "..-details.txt" These contain my preliminary assessments of CL's initial technical comments. I still intend to break out a couple of specific issues. But these are good to read now, to orient yourself to the coming issue discussions. If you wish to start commenting now, *before* breakout of individual issues, please do this: copy-paste the whole section for the particular comment, into your email body, and send it to the TC list with a subject like "Issue CL-c2: 'picseqno' in fragments". It will thereby become the root of the issue discussion in the archive thread. -Lofton.
======================== CL-d1 ========================
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.
***LH Preliminary Assessment***
Seems straightforward updating of reference. Todo: look at CharMod as suggested.
======================== CL-d2 ========================
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
***LH Preliminary Assessment***
Seems straightforward updating of reference.
======================== CL-d3 ========================
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.
***LH Preliminary Assessment***
WebCGM is pretty unspecified here. There are a couple of things that
need to be looked at: Esc 45 (alpha transparency), sRBG (registered),
and RGBA/sRGBA (registered). Esc45 only 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 others. WebCGM (IMO) has no
notion of "group opacity", like SVG. This is all 1.0 functionality, and
the addition of grnode doesn't impact that.
I don't know the answers about color space for compositing (is the
question even relevant), nor whether alpha is linear.
This needs to be assigned to someone for research, to see
what answers there are, and where it is under-specified or unspecified.
Once again, 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.
Conclusion. Assign or get volunteer.
======================== CL-d4 ========================
[[[
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).
***LH Preliminary Assessment***
Agreed. It's editorial. Fix it.
======================== CL-d5 ========================
[[[
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)?
***LH Preliminary Assessment***
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. A requirement to do so did not make it into the
priority requirements for 2.0. They were discussed, and explicitly
deferred again (until after 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 bitblts.
Therefore (IMO) questions such as 'bidi block' or 'text to speech' mapping are
unanswerable, until appropriate requirements and more precise specification
are added to WebCGM.
It would be good to research this a bit and write a coherent statement.
Conclusion. Assign or get a volunteer.
======================== CL-d6 ========================
[[[
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?
***LH Preliminary Assessment***
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 specification, 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.)
Conclusion. See CL-d5.
======================== CL-d7 ========================
[[[
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.
***LH Preliminary Assessment***
No, this need editorial clarification. It was only meant to express
that you can link CGM-to-other-stuff, and you can link other-stuff-to-CGM.
======================== CL-d8 ========================
[[[
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 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
***LH Preliminary Assessment***
This wording should have been changed and was missed. There is a
similar sentence in 3.2.2.3 which *was* changed, simultaneous with
fixing 3.1.1.4 (non-ASCII in URIs). Those changed 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, correct
readings of 1.0).
Conclusion. Fix it as just described.
======================== CL-d9 ========================
In general URL should not be used, its an undefined term. Either
URI or (better) IRI should be used.
***LH Preliminary Assessment***
Right, this is an editorial fix that should be made (and search whole
document for "URL".
======================== CL-d10 ========================
[[[
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.
***LH Preliminary Assessment***
Yes, it should say that. The issue is bigger, however -- see CL-c2 and
CL-c7.
==== got to 2.7.2 ======
(LH note -- so we should probably expect a fair amount more.)
======================== CL-c1 ======================== 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. ***LH Preliminary Assessment*** This one confuses me a little. I suspect that CL may have misread the intent. IMO, the intent here was to support "reasonable" i18n in object names and links, but not to support such things as 'bidi' (string that are composed of unicode characters from different direction languages, e.g., some english chars (L2R), then some arabic (R2L), then some english, all in the same object id. The first quoted paragraph is correct -- utf8 & utf16 are allowed anywhere that S and SF data are allowed (if properly declared etc). The second paragraph was an attempt to avoid getting tangled up in URI/IRI/CharMod issues that are beyond the requirements of the 2.0 constituency, but that could take a long time to resolve. (Are there any such? Like bidi?) I believe that the flexibility in names is there. But ... is there any implication that we must support bidi in names, etc? Conclusion. We do support internationalized SF (even in id), as well as S, but I'm unsure about the implications of some of the more complicated unicode questions. Some research would help. ======================== CL-c2 ======================== WebCGM alowed multiple pictues per file but warned against using it (deprecated in effect). WebCGM 2.0 requires that only a single picture is used. Can a WebCGM 2.0 picture link to a given picture in a multi-picture WebCGM 10 file? ***LH Preliminary Assessment*** 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: a.) What does a 2.0 viewer do with an external pseq=2 frag/link into a 2.0 file? b.) What happens with a 2.0 viewer handling a 1.0 file containing a pseq=2 frag/link? c.) Can a 2.0 file have a pseq=2 fragment pointing to a 1.0 file? Question. Other than test suite files (ATA, WebCGM), is anyone aware of any multi-pic files in practice? If the answer is "no", then to some extent it doesn't matter how we answer a-c. Since we don't specify error reactions of viewers, we could treat #a: map it to the 1st picture (and inform user), which would match the 1.0 spec for an out of range picture number. Proposal for #c: "no", invalid data. Proposal for b: like #a. For #c, I would have been inclined to say "handle it as 1.0 viewer should handle it", if multi-pic metafiles were common. But ... it doesn't matter, if there are none. Note. This illustrates a general problem with changing 1.0 specs for 2.0. We don't have a clear policy about how 2.0 viewers need to handle valid 1.0 content. Our deprecation policy (7.2.2) is slightly wooly, "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. This doesn't say whether 2.0 viewers must support 1.0 metafile content, or must support 1.0 constructs that come from non-CGM content. Conclusion. Probably can take "strict" approach, since no real-world impact. (It's like deleting an unimplemented feature at W3C CR stage of a new standard.) The general question of "2.0 viewer handling of valid 1.0 metafiles" probably deserves some more thought and discussion. ======================== CL-c3 ======================== 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.) References does not describe UTF-16 b.) not clear if non-ascii text is allowed in id ***LH Preliminary Assessment*** #a is purely editorial. #b, it is absolutely our intent that non-ASCII is allowed in apsid parameter -- see last sentence of 3.1.1. Conclusion: moot. (See however CL-c1, discussion about scope of non- ASCII support.) ======================== CL-c4 ======================== 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) ***LH Preliminary Assessment*** I don't understand his comment. As far as I can see, 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. Am I missing some ambiguity in the wording? See PPF, T.14.5. Conclusion. Pursue clarification with CL. ======================== CL-c5 ======================== 3.1.1.4 Non-ASCII characters in URIs I think that is OK ***LH Preliminary Assessment*** Great! We got it right. (This should also be the subject of a clarifying erratum for 1.0.) ======================== CL-c6 ======================== [[[ 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. ***LH Preliminary Assessment*** I'm unsure what is the problem. CL 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 else see what the problem is? Conclusion. Pursue clarification with CL. ======================== CL-c7 ======================== 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. ***LH Preliminary Assessment*** See CL-c2. Conclusion. See CL-c2 ======================== CL-c7 ======================== 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. ***LH Preliminary Assessment*** First, the *default* is changed to zoom+newHighlight. Second, the 2.0 mapping rule for viewers is "map view_context to zoom+newHighlight". I'm not sure that it would make sense to constrain WebCGM 2.0 by the 1.0 rules, just because they 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. Todo. Look at SVG to see what the problem might be. Conclusion. Pending, but *WebCGM* 2.0 requirements should rule. ======================== CL-c8 ======================== 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. ***LH Preliminary Assessment*** 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." Conclusion. Fix wording. ======================== CL-c9 ======================== [[[ 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. ***LH Preliminary Assessment*** This comment confuses me. 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 CL missed this point. Anyway, this table summarizes 1.0 behaviors and syntax carried forward unchanged into 2.0, and there are no 2.0 Requirements to change this around for 2.0, and there are no 2.0 Requirements for aligning it all with CDF (go to w3.org home page and look up CDF). It predates CDF by 6 years. Conclusion. Clarify with CL. (And be alert for "creeping requirements" -- things like adding CDF compatibility, which is *not* a requirement of the principal constituency, and which could delay delivery of 2.0 to the constituency that wrote the 2.0 requirements.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]