WML the % Sign Affected Areas (was Re: Material for next week's WG4 Teleconference: Proposed Responses to DRs 08-0001 through 08-0008, and 09-0033)

[Shawn Villaron]

I wonder if we're headed down a slippery slope with respect to these changes.  For example, are you saying that when defining simple types, we should a) never describe what they're used for, and b) never have examples?  If so, that constitutes a radical editorial change to the standard, and likely warrants a separate defect report, no?  Perhaps I'm misunderstanding your mail.  Would it be possible for you to provide the proposed solution for the ST_TextScalePercent issue you identified below so that I can better understand your request?

For what it's worth, I don't see any harm in a) describing that the ST is used for, nor in b) having examples in ST definitions.  The standard is quite large, and I personally have found this information useful in implementing and debugging our implementation.  I suspect that other implementers, both large and small, would gain benefit from this, too.  

Also, given our existing workload, I wonder if cleaning up the spec like this ( arguably valuable editorial improvements ) is the right investment of WG4 resources?  I've personally seen defect reports that are essential that we handle in a timely manner ( missing data, incorrect constraints, etc. ) as those will have a clear impact on people's ability to implement interoperable solutions.  For editorial changes that are limited in scope, I think we should fix those.  But large editorial changes to the spec like this seem optional.

shawn 

-----Original Message-----
From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp] 
Sent: Wednesday, April 29, 2009 7:31 AM
To: SC 34 WG4
Subject: WML the % Sign Affected Areas (was Re: Material for next week's WG4 Teleconference: Proposed Responses to DRs 08-0001 through 08-0008, and 09-0033)

>17.18.xx  ST_TextScalePercent (Text Expansion/Compression Percentage)

>This simple type specifies that the percentage by which the contents of 
>a run shall be expanded or compressed with respect to its normal
>(100%) character width, with a minimum width of 1% and maximum width of 
>600%.

Since this paragraph is about a simple type rather than an element or attribute, this paragraph should not mention expansion or compression.

>[Example: Consider a run of text which must be compressed to 200% when 
>displaying each character within the contents of the run. This 
>constraint is specified using the following WordprocessingML:
...
>This run explicitly declares that the w value is 50%, so the contents 
>of this run appear at 50% of their normal character width by 
>compressing the width of each character. end example]

This example already appears in 17.18.95 and is thus redundant.

>9.10.xx  ST_TextScaleDecimal (Text Expansion/Compression Percentage)

>This simple type specifies that the percentage by which the contents of 
>a run shall be expanded or compressed with respect to its normal
>(100%) character width, with a minimum width of 1% and maximum width of 
>600%.

Again, this paragraph should not mention expansion or compression.

>[Example: Consider a run of text which must be expanded to 300% when 
>displaying each character within the contents of the run. This 
>constraint is specified using the following WordprocessingML:
>
><w:rPr>
>  <w:w w:val="300"/>
></w:rPr>
>This run explicitly declares that the w value is 300, so the contents 
>of this run appear at 300% of their normal character width by expanding 
>the width of each character. end example]

This example is inappropriate, since this subclause is about a simple type rather than an element or attribute.




Cheers,
Makoto