Character Repertoire question

[Lofton Henderson <lofton@rockynet.com>]

WebCGM implementors (all), I'd like your feedback on this one...

At 02:36 PM 10/5/2005 -0600, Robert Orosz wrote:
>[...]
>2) Yes, you are absolutely correct.  The identifier parameter of both the
>Begin Picture and Begin APS elements is of type SF, so T.14.5 applies to
>both elements (this is also pointed out in section 9.5.4.6 of CGM99).  The
>first bullet in the third rule of 3.1.1.3 applies the XML name rule to
>objid.  This rule places restrictions on the overall character repertoire,
>i.e. it cannot be any Unicode character.  Therefore, there is the potential
>for a Begin APS identifier in a WebCGM 2.0 file to contain a character that
>is not allowed in a WebCGM URI fragment.  However, there is a wrinkle :-(.
>
>Section 3.3 (Content Model) contains this in the DTD.
>
><!ATTLIST grobject
>   id           ID         #REQUIRED
>...
>
>and the same id attribute declaration is present for para, subpara, etc.  An
>attribute type of ID in XML must conform to the XML name rule.

This is indeed stated explicitly in 3.1.1.3, #3, first bullet (which is 
unchanged since WebCGM 1.0).


>Now, here is the wrinkle.  Section 3.3 is labeled as informative
>(non-normative).  WebCGM 1.0 Second Release did not apply the "normative" or
>"informative" label to individual chapters and subsections, so the entire
>specification including Section 3.3 is taken to be normative.  The scenario
>that I describe above is not possible in a valid WebCGM 1.0 file because the
>Begin APS identifier parameter in the WebCGM 1.0 file must conform to the
>XML name rule.  MetaCheck in fact, will flag a WebCGM 1.0 2nd Edition
>profile violation if it encounters a Begin APS id in a WebCGM 1.0 file that
>does not conform to the XML name rule.  An easy way to check this for anyone
>that has MetaCheck, is to generate a WebCGM 1.0 file containing a APS with a
>digit as the first character in the APS identifier.
>
>I assume that the labeling of Section 3.3 as informative is an editorial
>glitch;

No, this was an explicitly argued issue, many months ago.  There was 
objection to using an XML DTD to define the content model of WebCGM, a 
binary non-XML format (tho' XML-like in some structural ways).  It was also 
deemed to be redundant or contradictory with other stuff in Ch.3 (e.g., see 
last sentence of 3.3, which is 1.0 vintage).

Therefore we resolved to make it explicitly Informative, and to ensure that 
the normative rules were complete elsewhere in Ch.3.  So for example we 
added an EBNF content-rule snippet to each subsection of 3.1.1.

>i.e. the Editor did not fully think through the ramifications before
>typing that sentence.  If so, I apologize for not catching it in my Chapter
>3 review.  We can fix the editorial error and there is no possibility for a
>Begin APS id in a WebCGM 2.0 file to contain characters not allowed in the
>WebCGM URI fragment just like the WebCGM 1.0 case.  The first bullet in rule
>3 of section 3.1.1.3 becomes redundant like it was in WebCGM 1.0.  A little
>redundancy here and there doesn't hurt.

But the necessary restrictive specification is there in 3.1.1.3, even if 
3.3 is informative.  But see my next question...


>If the labeling of Section 3.3 as informative is not an editorial glitch,
>then this can be handled by changing the wording of the last paragraph of
>3.1.1.3.  Basically, change occurrences of "picid" to "objid and picid" and
>massage the surrounding text appropriately.

The real question here is whether the *restrictive* rules in 3.1.1.3 apply to:

1.) picid and objid (apsid) occurrences in URL fragment instances;
2.) picid and objid (apsid) occurrences (in APS and BegPic elements) in 
WebCGM content instances;
3.) both.

It appears that the MetaCheck authors thought "#3. both" for objid (apsid), 
and I think the 3.1.1.3 text supports this (or can be read as supporting it 
-- it's slightly vague).

It appears that the WebCGM 1.0 authors thought #1 for picid (3.1.1.3, #3, 
3rd bullet clearly supports this, as does the last pgph of 3.1.1.3).

If implementors have done it this way, we ought to leave it alone (other 
than clarifying), even if it is a bit messy or "odd".  (We want to avoid 
Substantive Changes, if possible.)

Implementors, what do you think?

Regards,
-Lofton.