DR 09-0055, PML, Presentation: Type of the attribute pitchFamily is too loose

Fri Jun 3 23:09:10 CEST 2011

I have removed the schema changes from my document, and added the modifications to each of the other sections Murata-san mentioned below. The existing schema changes (revision 133) are not quite complete as they don't include the utilising of the new simple type in the extra subclauses. I'm going to see if I can check in the correct changes before Berlin.

New version of the required changes to the standard is attached.

Chris

-----Original Message-----
From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp] 
Sent: 23 May 2011 07:04
To: Chris Rae
Cc: Rex Jaeschke (rex at RexJaeschke.com); Murata
Subject: Re: DR 09-0055, PML, Presentation: Type of the attribute pitchFamily is too loose

Chris and Rex,

> If I understand this correctly these are schema-only changes?

I think that we have to change the description of @pitchFamily for the
other subclauses (see below) as well.   Since these subclause rely on a
single complex type CT_TextFont, we only have to change it.

> 21.1.2.3.1  cs (Complex Script Font)
> 21.1.2.3.3  ea (East Asian Font)
> 21.1.2.3.7  latin (Latin Font)
> 21.1.2.3.10  sym (Symbol Font)
> 21.1.2.4.6  buFont (Specified)

Cheers,
Makoto

> Hi Murata-san - sorry for the delay on this, I was busy checking up on these changes internally.
> 
> The edits look good; I think you're quite right about using 20.1.10 instead of 19.7.56. I also think it would be sensible to change all of the other pitchFamily instances as well.
> 
> If I understand this correctly these are schema-only changes?
> 
> Chris
> 
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA 
> Makoto
> Sent: 17 February 2011 01:50
> To: Chris Rae
> Cc: Rex Jaeschke (rex at RexJaeschke.com); MURATA Makoto (FAMILY Given)
> Subject: Re: FW: DR 09-0055, PML, Presentation: Type of the attribute 
> pitchFamily is too loose
> 
> Chris and Rex,
> 
> I am afraid that we really screwed up when we closed this DR in WG4.
> 
> First, I committed the required schema changes. They are parts of
> 
> https://www.assembla.com/code/IS29500/subversion/nodes/branches/Part1D
> COR2?rev=133
> 
> and
> 
> https://www.assembla.com/code/IS29500/subversion/nodes/branches/Part4D
> COR2?rev=133
> 
> If you know how to use subversion, this repository is extremely useful.  My work required for schema maintenance is now extremely easier than before.  The DCOR1 and FPDAM1 were really painful, but I now enjoy schema hacking for OOXML.
> 
> If you don't, here is the changes I did.
> 
> 1) dml-main.rnc (for both Parts 1 and 4)
> 
> a_ST_PitchFamily =
>  xsd:byte "00" | xsd:byte "01" | xsd:byte "02" | xsd:byte "16" |  xsd:byte "17" | xsd:byte "18" | xsd:byte "32" | xsd:byte "33" |  xsd:byte "34" | xsd:byte "48" | xsd:byte "49" | xsd:byte "50" |  xsd:byte "64" | xsd:byte "65" | xsd:byte "66" | xsd:byte "80" |  xsd:byte "81" | xsd:byte "82"
> 
> is added immediately before the def of a_CT_TextFont
> 
>   attribute pitchFamily { xsd:byte }?,
> 
> in a_CT_TextFont is replaced by
> 
>   attribute pitchFamily { a_ST_PitchFamily }?
> 
> 2) dml-main.xsd (both Parts 1 and 4)
> 
>   <xsd:simpleType name="ST_PitchFamily">
>    <xsd:restriction base="xsd:byte">
>      <xsd:enumeration value="00"/>
>      <xsd:enumeration value="01"/>
>      <xsd:enumeration value="02"/>
>      <xsd:enumeration value="16"/>
>      <xsd:enumeration value="17"/>
>      <xsd:enumeration value="18"/>
>      <xsd:enumeration value="32"/>
>      <xsd:enumeration value="33"/>
>      <xsd:enumeration value="34"/>
>      <xsd:enumeration value="48"/>
>      <xsd:enumeration value="49"/>
>      <xsd:enumeration value="50"/>
>      <xsd:enumeration value="64"/>
>      <xsd:enumeration value="65"/>
>      <xsd:enumeration value="66"/>
>      <xsd:enumeration value="80"/>
>      <xsd:enumeration value="81"/>
>      <xsd:enumeration value="82"/>
>    </xsd:restriction>
>   </xsd:simpleType>
> 
> is added immediately before the def of  CT_TextFont
> 
>     <xsd:attribute name="pitchFamily" type="xsd:byte" use="optional"
> default="0"/>
> 
> in CT_TextFont is replaced by
> 
>     <xsd:attribute name="pitchFamily" type="ST_PitchFamily"
> use="optional" default="0"/>
> 
> 
> In the current DR log, "ST_PitchFamily (Pitch Family)" is mistakenly added to 19.7.56.
> However, since it is part of dml-main.xsd and dml-main.rnc, it should be added to 20.1.10.
> 
> Accordingly, "Note: The W3C XML Schema definition of this simple 
> type's content model
> (ST_PitchFamily) is located in §A.3. end note]" has to be revised by replace A.3 by A.4.1.
> 
> BTW, pitchFamily appears in many places, namely
> 
> 19.2.1.13  font (Embedded Font Name)
> 21.1.2.3.1  cs (Complex Script Font)
> 21.1.2.3.3  ea (East Asian Font)
> 21.1.2.3.7  latin (Latin Font)
> 21.1.2.3.10  sym (Symbol Font)
> 21.1.2.4.6  buFont (Specified)
> 
> I think that we have to change all occurrences of the  attribute 
> pitchFamily in these places in the same manner, but the current 
> wording changes
> 19.2.1.13 only.
> 
> 
> 
> Cheers,
> Makoto
> 
> 2011/2/17 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
> > Chris and Rex,
> >
> > Later today, I will provide schemas.
> >
> > 2011/2/16 Chris Rae <Chris.Rae at microsoft.com>:
> >> Managed to dig this up - does this finish 09-0055?
> >>
> >> Chris
> >>
> >> -----Original Message-----
> >> From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
> >> Sent: 25 November 2010 09:36
> >> To: Chris Rae
> >> Subject: DR 09-0055, PML, Presentation: Type of the attribute 
> >> pitchFamily is too loose
> >>
> >> Chris, I'm making a detailed pass over all DRs that we've closed since COR1 and AMD1, but not yet balloted/published, to make sure they are complete w.r.t sufficient details that their resolutions can simply be copied verbatim to a future AMD or COR.

> >>
> >> The resolution for this DR was very much underspecified w.r.t the details although the intent is clear.
> >>
> >> Based on my Aussie ingenuity (and some coin tosses), attached is my take at the details. While I think I'm on the right track, I have some questions and need some input from you to complete this DR's write up. Please check thoroughly my edits.
> >>
> >> 1. You proposed the new simple type be called ST_pitchFamily; however all other such types appear to start with an uppercase letter, so I've "corrected" that. Was this a typo or is MS actually implementing this using the lowercase name?
> >
> > Yes, it should be ST_PitchFamily.  With the exception of 
> > ST_rwColActionType in sml.xsd, every simple type name matches S_[A-Z].
> >
> >> 2. I've taken a shot as defining the narrative for the new simple type, but if you could supply an opening sentence that would be great.
> >>
> >> 3. I put "Pitch Family" inside the parens on the ST subclause header, which seemed the obvious thing to do.
> >
> > Correct.
> >
> >> 4. It seems to me that the values of the new simple type should be moved to the simple type definition, and I have done that; however, in (all?) other cases of enumerated types with value lists, each enumeration has had a name.
> >> But the values 00-82 aren't really names, are they? IS the table move correct, and if so, is it correct? I don't think so.
> >
> >
> > I agree that all other enumerated values are non-numeric (I did 
> > check the strict XSD schemas).
> > This case is a bit special since we are mimicking Panose.  Moreover, 
> > we cannot destroy exisiting documents.  So, I can live with the 
> > proposed simple type defintion, but 0x52 in the table and 82 in the 
> > schema are confusing.  Each table entry should use decimal numbers 
> > and provide hexadecimal values in the description.
> >
> > Cheers,
> > Makoto
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0055 proposed changes.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 86713 bytes
Desc: DR 09-0055 proposed changes.docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20110603/fa03b7ca/attachment-0001.bin>