RE: [cgmo-webcgm] RE: Character Repertoire question

[Lofton Henderson <lofton@rockynet.com>]

At 03:28 PM 10/6/2005 -0600, Robert Orosz wrote:
>Lofton,
>
>One more thought.  Since section 3.3 of the WebCGM spec is informative
>rather than normative, shouldn't the normative sections of WebCGM 2.0 be
>"scrubbed" of any references to section 3.3?
>
>An example would be the last sentence in T.15.9 of the PPF.

Good catch.

Indeed, if it is a "normative reference", then it should be changed.  I.e., 
it can't say, "see 3.3 for the exact content model."  Any instances of this 
need to be changed to point at the proper normative bits.

Informative reference is okay, e.g., "see 3.3 for an illustration / example 
of ..blah.."

-Lofton.


>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Thursday, October 06, 2005 2:55 PM
>To: Robert Orosz
>Cc: cgmo-webcgm@lists.oasis-open.org
>Subject: Re: [cgmo-webcgm] RE: Character Repertoire question
>
>
>At 10:26 AM 10/6/2005 -0600, Robert Orosz wrote:
> >Lofton,
> >
> >Section 3.1.1 is titled "URI fragment specification"
> >Section 3.1.1.3 is titled "Fragment Character Repertorie"
> >
> >I don't see how this applies to object identifiers in the WebCGM file; i.e.
> >I pick "1" in your list below.
>
>I think it was poorly written for 1.0, but nevertheless did intend that,
>despite the titles (above).  I was the programmer who upgraded MetaCheck
>for WebCGM profile checking.  I remember using that section to get the
>rules.  I didn't use the DTD ATTLIST to get the rules.  I'll also point out
>that #3, 3rd bullet, is quite explicit about addressing the WebCGM content
>(for picid), despite the titles.
>
>Be that as it may...
>
> >I also interpreted those sections in WebCGM
> >1.0 2nd Ed. exactly the same way.  However, section 3.3 in WebCGM 1.0 tells
> >me that object identifers must follow the XML name rule.  Section 3.3 in
> >WebCGM 2.0 is informative only, so it cannot answer that question.
> >
> >My recommended resolution is to add a sentence to each of sections 3.2.1.1
>-
> >3.2.1.5 stating that the application structure identifier parameter must
> >follow the XML name rule.  That puts an explicit requirement on the WebCGM
> >file itself rather than just the WebCGM fragment.
> >
> >I don't think that's a substantive change, it's just bringing forward the
> >WebCGM 1.0 requirement.
>
>Yes, on that we agree -- I suspect everyone has interpreted the objid
>(apsid) in WebCGM instances to be restricted per XML name (but would still
>like to hear from others).  In fact, in the 1.0 development days, I think
>we had a discussion about it, because we were already anticipating XML
>companion files, and wanted that there not be a mismatch between WebCGM
>content (apsid) and XML companion (id).
>
>We can fix it (editorially) as you suggested in 3.2.1.1-5, or by clarifying
>3.1.1/3.1.1.3 and their titles.
>
>Other thoughts?
>
>-Lofton.
>
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Thursday, October 06, 2005 10:01 AM
> >To: Robert Orosz
> >Cc: cgmo-webcgm@lists.oasis-open.org
> >Subject: Character Repertoire question
> >
> >
> >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.