COR3 issue: ST_PitchFamily

[John Haug]

Background: E-mail “A second COR for 29500-1 and the type ST_PitchFamily in DML” forwarded below
Background: E-mail “ST_PitchFamily in dml-main.xsd” (latest reply 2015-07-12)

Summary:

·         DR 09-0055: CT_TextFont at pitchFamily changed to be of new type ST_PitchFamily (missing in DCOR)

·         DR 09-0037 already removed CT_TextFont at charset/panose/pitchFamily

·         --> Proposed: back out DR 09-0055, re-open it, look at it from scratch

·         ** Why was 09-0037 resolved as it was? ("Reviewed Shawn’s email of 2010-03-18. We chose Choice 2, “Remove the attributes from the standard”." The e-mail is the same as in the DR log from 2009-06-17.)
Rex> Yes it looks like we need to reconsider these, and as MM suggested in his mail, “Re: A second COR for 29500-1 and the type ST_PitchFamily in DML”, on 2015-07-30 [JH: Forwarded below], we NOT include this in the 2nd COR, but rather take our time and fix it next time around. I suggest making a new DR that points to these two.

I think these two DRs need to be looked at together to come to a final conclusion.  Because there is such a significant amount of text changed here, I think publishing as is would be a problem and that we should correct this before the Beijing meeting so the new DCOR ballot (COR3b?) will have it.

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Thursday, July 30, 2015 2:58 PM
To: Rex Jaeschke <rex at rexjaeschke.com>
Cc: John Haug <johnhaug at exchange.microsoft.com>; MURATA Makoto (FAMILY Given) <eb2m-mrt at asahi-net.or.jp>
Subject: Re: A second COR for 29500-1 and the type ST_PitchFamily in DML

Although I agree that we should revise CT_EmbeddedFontListEntry
and introduce a type (CT_EmbeddedTextFont) without the three
attributes, I do not think that this change is a must for this
consolidation.  It is not very difficult to address this defect, but
if we start to incorporate not-so-difficult DRs as part of the
new COR for the remedy, we will run the risk of delaying
it and the consolidated text for months.

Regards,
Makoto

2015-07-31 0:07 GMT+09:00 Rex Jaeschke <rex at rexjaeschke.com<mailto:rex at rexjaeschke.com>>:
Yes, the changes proposed in DR 09-0037 went into COR2 and 29500:2012.

John, if you agree that we have a conflict between 09-0037 and 09-0055, I’ll re-post this thread to the committee and create a new DR for it. In that case, should we delay a new COR for resolution of this? After all, it is not related to the recent COR and consolidation.

Rex

From: eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com> [mailto:eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com>] On Behalf Of MURATA Makoto
Sent: Thursday, July 30, 2015 2:10 AM
To: Rex Jaeschke <rex at rexjaeschke.com<mailto:rex at rexjaeschke.com>>
Subject: Re: A second COR for 29500-1 and the type ST_PitchFamily in DML

Ouch!

I think that  DR 09-0037 should have introduced a new complex type,
say CT_EmbeddedTextFont, to dml-main.xsd.   Its definition should be:

  <xsd:complexType name="CT_EmbeddedTextFont">
    <xsd:attribute name="typeface" type="ST_TextTypeface" use="required"/>
  </xsd:complexType>

This complex type should be used only for 19.2.1.13  font (Embedded Font Name) .

  <xsd:complexType name="CT_EmbeddedFontListEntry">
    <xsd:sequence>
      <xsd:element name="font" type="a:CT_EmbeddedTextFont" minOccurs="1" maxOccurs="1"/>
...

Then, no other elements will be affected by this change.

Yes, we have to revise 19.2.1.13  font (Embedded Font Name)  significantly.
Are the changes in DR 09-0037  incorporated now?

Regards,
Makoto


2015-07-30 5:23 GMT+09:00 Rex Jaeschke <rex at rexjaeschke.com<mailto:rex at rexjaeschke.com>>:
[I’m starting off with just the 3 of us. If/when we make progress, I’ll post to the whole of WG4.]

One of the issues Murata-san raised recently (See issue Category 2a from the teleconference minutes of 2015-07-28.) was the fact that the definition of the new type we added way back, ST_PitchFamily, did not have a formal description in the Simple Types clause. This was supposedly resolved in DR 09-0055. When I first had a detailed look at that DR, I found that quite a lot of text that WG4 probably (I can’t be certain) agreed to, didn’t make it into the COR and subsequent consolidated reprint.

Today, I started creating a new DR to fix any errors that occurred in processing DR 09-0055. Unfortunately, this looks like it has led to a larger problem.

We adopted the resolution to DR 09-0055 at the Berlin Meeting on 2011-06-20/22.

That resolution added the schema for the new type, ST_PitchFamily, and changed CT_TextFont to refer to that new type. This occurred for both Parts 1 and 4. However, the narrative definition of the type was NOT added, even though it existed in the earlier part of the DR log. Clearly, that seems wrong; if we added the schema for a new simple type, we should have added the corresponding text to describe it.

Separately, 15 months earlier, at the Stockholm meeting on 2010-03-23/25, we closed out DR 09-0037, which involved REMOVING the following attributes from CT_TextFont: charset, panose and pitchFamily. These removals are reflected in the resulting COR and the following consolidated reprint, 29500-2012. However, if the pitchFamily attribute no longer existed, it couldn’t be changed by DR 09-0055. But if we remove these changes from DR 09-0055, the only changes left are to define the new type’s schema, but never to refer to it anywhere in the schema, which sounds very strange, indeed.

Looking at DR 09-0037 further, although we agreed to remove the 3 attributes, the resolution and resulting COR did NOT actually remove them from the schema definition for that type. It seems to me that they should have. Also, a number of other types contain elements of type CT_TextFont, yet 09-0037 didn’t say to remove those 3 attributes from them (see §21.1.2.3.x for cs, ea, latin, sym, and buFont). Also, even after the attributes were removed from the narrative in 19.2.1.13 font (Embedded Font Name), an example remains there that uses the attributes pitchFamily and charset, which were removed!

Bottom line, in the unused proposal text of DR 09-0055, attribute pitchFamily was to be greatly simplified with a pointer made to the new type ST_PitchFamily. Yet, DR 05-0037 said to remove this attribute altogether. All the other edits in the unused proposal of DR 09-0055 refer exactly to the descriptions of the same attribute (pitchFamily) in the cs, ea, latin, sym, and buFont elements mentioned earlier. So it seems that all the proposed text (both used and unused) hits all the related places in the spec.

It is clear that the resolutions we can imply from what was recorded in DRs 09-0037 and 09-0055 can’t coexist, as they are contradictory. If we adopt the supposedly omitted text from 09-0055, we contradict the intent of 09-0037.

Maybe the solution is simple: adopt option 1 from DR 09-0037 instead of Option 2, massaging it to accommodate DR 09-0055’s complete proposal.

Rex




--

Praying for the victims of the Japan Tohoku earthquake

Makoto



--

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150814/0eda71a4/attachment-0001.html>