From owner-incits-v1@incits-v1.org Fri Jun 15 13:25:29 2007 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OaeAwUVPWOG8Z8NfnKH5+Q)" Date: Fri, 15 Jun 2007 13:24:20 -0700 From: Doug Mahugh Subject: RE: INCITS-V1: Discussing comments In-reply-to: Sender: owner-incits-v1@incits-v1.org To: "incits-v1@incits-v1.org" Reply-to: incits-v1@incits-v1.org Content-language: en-US Accept-Language: en-US Thread-topic: INCITS-V1: Discussing comments Thread-index: AcetC13mFGM8oHDtQ+2xQ5qL275IRgCf555w acceptlanguage: en-US X-PMX-Version: 5.2.0.264296 X-MS-Has-Attach: X-MS-TNEF-Correlator: --Boundary_(ID_OaeAwUVPWOG8Z8NfnKH5+Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Rob, I agree it's unfortunate that our last call only covered two topics, but I = don't think this was due to discussion about the wording of a possible comm= ent response to Ecma. That was a brief portion of our call, and prior to t= hat we had spent about 30 minutes on procedural matters, and then roughly o= ne hour each on two topics. The first topic was your comment about Part 1, Section 15.2.14, and your re= commendation that we propose Ecma add a format for XML-based printer settin= gs to the spec. You spoke at length about the potential interoperability p= roblems that could be caused by use of a DEVMODE binary structure, although= I and others noted that DEVMODE is only mentioned in a non-normative examp= le. We discussed your recommendation that XPS's PrintTicket format be used= for this. XPS is not a standard, but you suggested it was likely to becom= e one, so we should consider PrintTicket a precedent for XML-based represen= tation of printer settings. Stephen Peront stated his opinion that defining an XML-based standard for p= rinter settings was unlikely to create true interoperability due to differe= nces in printer drivers. He also noted that since there is no current stan= dard for XML-based representation of printer settings, we were treading int= o new territory and talking about creating a new standard in this area outs= ide the scope of DIS 29500. Your response was "Ecma hasn't been shy about = implementing new standards." I suggested that a new standard for printer settings might limit interopera= bility for Mac users who are accustomed to their Carbon printer settings mo= ving between users inside documents, unless Apple were convinced to support= this new approach. You said that ODF and PDF include such standards. I quo= ted the OpenDocument Fellowship web site regarding ODF's storage of printer= settings: "The settings.xml file contains information intended for use exc= lusively by the application that created the file. From the viewpoint of an= external application, there's very little of use in this file, so we'll ju= st take a brief look at it before bidding it a fond farewell." And so it went for about an hour. We then moved on to Patrick's comment ab= out repeated definitions of same-named attributes, and we discussed a few s= pecific examples from Patrick's Annex B. First we discussed the hRule attribute, which is used in two places. In se= ction 2.3.1.11, it refers to Frame Height Type, and in section 2.4.77 it re= fers to Table Row Height Type. In both cases the possible values are "auto= " (auto-size based on the contents of the frame or table row, and ignore th= e "h" attribute that specifies height), "atLeast" (the height should be at = least the value of the "h" attribute), and "exact" (the height should be ex= actly the height specified by the "h" attribute). In discussing hRule, it became clear that Patrick's comment actually encomp= asses several different questions: 1) Should the same attribute name should be used for the same concept in di= fferent contexts (i.e., different elements and/or different namespaces), or= should every attribute name should be unique across the entire spec? On t= his, we had disagreement. Some felt that each attribute name should be tru= ly unique, and therefore a large number of attributes should be renamed -- = hRuleFrame and hRuleTableRow, for instance. Others (myself included) felt = that it is easier to implement the spec if there is a smaller number of att= ribute names, and in particular if the same concept has the same name every= where it occurs. I pointed out that HTML uses "width" and "height" attribu= tes in many different places, and the response I got was that HTML isn't co= nsidered an example of quality standards writing. Perhaps true, but I thin= k that it would be harder for most people to write HTML if it had attribute= s like widthImage, widthTable, widthCell, and so on, instead of one "width"= attribute for all of the above. 2) Should the same attribute name should be used for different concepts in = different contexts? On this, we were in some disagreement as well, althoug= h more people agreed with this premise. For example, the attribute "h" spe= cifies page height in section 2.6.13, and it specifies the maximum y coordi= nate within a path coordinate system in section 5.1.11.15. I agree that it= would nice for this to be consistent, but as I said on the call I'd have a= hard time looking the developers I work with in the eye and telling them t= hat a change to this attribute name would deliver enough value to be worth = doing. I said that seemed like a tax on early adopters like Xinnovation an= d 3Sharp, and Jon responded that standards bodies are expected to never giv= e consideration to existing implementations in their work. 3) Should the same attribute, in the same context (same namespace/element),= have multiple and/or different definitions within the spec? On this, ther= e was strong consensus that it should not. I felt that this conversation about Patrick's comment was productive, becau= se it helped us identify these areas of agreement and disagreement among th= e V1 members. I agree that we need to up the pace, especially since we're not creating a = standard but rather evaluating an existing standard that is going through t= he FastTrack process. I'm not familiar with the work in BSI that you allud= ed to, but if they're truly moving much faster than us then I can't imagine= they're spending time on things like examples in non-normative text or pro= posed increases in the scope of DIS 29500. Regards, Doug From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org] = On Behalf Of robert_weir@us.ibm.com Sent: Tuesday, June 12, 2007 9:05 AM To: incits-v1@incits-v1.org Subject: RE: INCITS-V1: Discussing comments I'd just note that at the previous call we were able to process around 40 t= echnical comments in 2 1/2 hours, and in this last call were barely able to= process 2, and along the way had some lengthy discussions about whether we= should word a request as, "We request that Ecma do..." versus "Ecma should= please consider...". So when we compare our accomplishment in the last meeting with the level of= technical review being accomplished by the BSI, I think yes, we should be = embarrassed. We're not effectively performing our TAG duties for INCITS or= JTC1. That's my opinion. I'll reply in more detail to your concerns, Stephen, in an email. Regards, -Rob ___________________________ Rob Weir Software Architect Workplace, Portal and Collaboration Software IBM Software Group email: robert_weir@us.ibm.com phone: 1-978-399-7122 blog: http://www.robweir.com/blog/ owner-incits-v1@incits-v1.org wrote on 06/12/2007 11:27:49 AM: > Hi Team... > > I'm very happy to be a part of the committee; I worked at Lotus and teame= d > up with IBM And Sun to contribute to the architecture and standardization= of > certain aspects of Java. PDF, ODF and OOXML represent a very powerful set= of > standards for the US, and I am glad to be here to contribute. This time > spent is a sacrifice of our personal time and effort for each of us... > > Speaking of which, I noticed the following comment out in the blog sphere= : > "I think we in the US should be ashamed at the stonewalling going on in V= 1" > (pasted from > http://www.robweir.com/blog/2007/06/hemidemisemiquavers.html#links). > > Does everyone agree that we should be ashamed of our contribution yesterd= ay? > > I realize this was my first meeting, but I was impressed with the level o= f > insight shared from each differing opinion and thought we made great > progress. I also agree with Patrick's suggestion to "make better use of t= his > reflector to discuss the various comments before we get into meetings, > thereby speeding up our consideration of each comment." > > I look forward to offering my contribution to make the USA proud of our > contribution! > > Have an awesome day! > > Cheers, > -Stephen > > -----Original Message----- > From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org= ] > On Behalf Of Mason, James David (MXM) > Sent: Tuesday, June 12, 2007 8:24 AM > To: incits-v1@incits-v1.org > Subject: RE: INCITS-V1: Discussing comments > > Sorry I had to drop out before the end, but the guys who pay the bills > were hollering for me from across the hall. > > Jim > > > --Boundary_(ID_OaeAwUVPWOG8Z8NfnKH5+Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Rob,

 

I agree it's unfortunate that our last call only covered two topics, but I don't think this was due to discussion about the wording of a possible comment response to Ecma.  That was a brief portion of our ca= ll, and prior to that we had spent about 30 minutes on procedural matters, and then roughly one hour each on two topics.

 

The first topic was your comment about Part 1, Section 15.2.= 14, and your recommendation that we propose Ecma add a format for XML-based pri= nter settings to the spec.  You spoke at length about the potential interoperability problems that could be caused by use of a DEVMODE binary structure, although I and others noted that DEVMODE is only mentioned in a non-normative example.  We discussed your recommendation that XPS's PrintTicket format be used for this.  XPS is not a standard, but you s= uggested it was likely to become one, so we should consider PrintTicket a precedent = for XML-based representation of printer settings.

 

Stephen Peront stated his opinion that defining an XML-based standard for printer settings was unlikely to create true interoperability = due to differences in printer drivers.  He also noted that since there is = no current standard for XML-based representation of printer settings, we were treading into new territory and talking about creating a new standard in th= is area outside the scope of DIS 29500.  Your response was "Ecma has= n't been shy about implementing new standards."

 

I suggested that a new standard for printer settings might l= imit interoperability for Mac users who are accustomed to their Carbon printer settings moving between users inside documents, unless Apple were convinced= to support this new approach. You said that ODF and PDF include such standards= . I quoted the OpenDocument Fellowship web site regarding ODF's storage of prin= ter settings: "The settings.xml file contains information intended for use exclusively by the application that created the file. From the viewpoint of= an external application, there’s very little of use in this file, so we&= #8217;ll just take a brief look at it before bidding it a fond farewell."=

 

And so it went for about an hour.  We then moved on to Patrick's comment about repeated definitions of same-named attributes, and = we discussed a few specific examples from Patrick's Annex B.=

 

First we discussed the hRule attribute, which is used in two places.  In section 2.3.1.11, it refers to Frame Height Type, and in section 2.4.77 it refers to Table Row Height Type.  In both cases the possible values are "auto" (auto-size based on the contents of th= e frame or table row, and ignore the "h" attribute that specifies height), "atLeast" (the height should be at least the value of th= e "h" attribute), and "exact" (the height should be exact= ly the height specified by the "h" attribute).

 

In discussing hRule, it became clear that Patrick's comment actually encompasses several different questions:

 

1) Should the same attribute name should be used for the sam= e concept in different contexts (i.e., different elements and/or different namespaces), or should every attribute name should be unique across the ent= ire spec?  On this, we had disagreement.  Some felt that each attribu= te name should be truly unique, and therefore a large number of attributes sho= uld be renamed -- hRuleFrame and hRuleTableRow, for instance.  Others (mys= elf included) felt that it is easier to implement the spec if there is a smalle= r number of attribute names, and in particular if the same concept has the sa= me name everywhere it occurs.  I pointed out that HTML uses "width&q= uot; and "height" attributes in many different places, and the respons= e I got was that HTML isn't considered an example of quality standards writing.  Perhaps true, but I think that it would be harder for most people to write HTML if it had attributes like widthImage, widthTable, widthCell, and so on, instead of one "width" attribute for all of= the above.

 

2) Should the same attribute name should be used for differe= nt concepts in different contexts?  On this, we were in some disagreement= as well, although more people agreed with this premise.  For example, the attribute "h" specifies page height in section 2.6.13, and it specifies the maximum y coordinate within a path coordinate system in secti= on 5.1.11.15.  I agree that it would nice for this to be consistent, but = as I said on the call I'd have a hard time looking the developers I work with in= the eye and telling them that a change to this attribute name would deliver eno= ugh value to be worth doing.  I said that seemed like a tax on early adopt= ers like Xinnovation and 3Sharp, and Jon responded that standards bodies are expected to never give consideration to existing implementations in their w= ork.

 

3) Should the same attribute, in the same context (same namespace/element), have multiple and/or different definitions within the spec?  On this, there was strong consensus that it should not.

 

I felt that this conversation about Patrick’s comment = was productive, because it helped us identify these areas of agreement and disagreement amo= ng the V1 members.

 

I agree that we need to up the pace, especially since we're = not creating a standard but rather evaluating an existing standard that is goin= g through the FastTrack process.  I'm not familiar with the work in BSI = that you alluded to, but if they're truly moving much faster than us then I can'= t imagine they're spending time on things like examples in non-normative text= or proposed increases in the scope of DIS 29500.

 

Regards,

Doug

 

 

From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org] On Behalf Of robert_weir@us.ibm.com
Sent: Tuesday, June 12, 2007 9:05 AM
To: incits-v1@incits-v1.org
Subject: RE: INCITS-V1: Discussing comments

 


I'd just = note that at the previous call we were able to process around 40 technical comme= nts in 2 1/2 hours, and in this last call were barely able to process 2, and al= ong the way had some lengthy discussions about whether we should word a request= as, "We request that Ecma do..." versus "Ecma should please consider...".  

So when w= e compare our accomplishment in the last meeting with the level of technical review being accomplished by the BSI, I think yes, we should be embarrassed= .  We're not effectively performing our TAG duties for INCITS or JTC1.  That's my opinion.

I'll repl= y in more detail to your concerns, Stephen, in an email.

Regards,


-Rob

_________= __________________

Rob Weir
Software Architect
Workplace, Portal and Collaboration Software
IBM Software Group

email: robert_weir@us.ibm.com
phone: 1-978-399-7122
blog: http://www.robweir.com/blog/


owner-incits-v1@incits-v1.org wrote on 06/12/2007 11:27:49 AM:

> Hi Team...
>
> I'm very happy to be a part of the committee; I worked at Lotus an= d teamed
> up with IBM And Sun to contribute to the architecture and standardization of
> certain aspects of Java. PDF, ODF and OOXML represent a very power= ful set of
> standards for the US, and I am glad to be here to contribute. This time
> spent is a sacrifice of our personal time and effort for each of u= s...
>
> Speaking of which, I noticed the following comment out in the blog sphere:
> "I think we in the US should be ashamed at the stonewalling g= oing on in V1"
> (pasted from
> http://www.robweir.com/blog/2007/06/hemidemisemiquavers.html#links= ).
>
> Does everyone agree that we should be ashamed of our contribution yesterday?
>
> I realize this was my first meeting, but I was impressed with the level of
> insight shared from each differing opinion and thought we made gre= at
> progress. I also agree with Patrick's suggestion to "make bet= ter use of this
> reflector to discuss the various comments before we get into meeti= ngs,
> thereby speeding up our consideration of each comment."<= br> >
> I look forward to offering my contribution to make the USA proud o= f our
> contribution!
>
> Have an awesome day!
>
> Cheers,
> -Stephen
>
> -----Original Message-----
> From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org]
> On Behalf Of Mason, James David (MXM)
> Sent: Tuesday, June 12, 2007 8:24 AM
> To: incits-v1@incits-v1.org
> Subject: RE: INCITS-V1: Discussing comments
>
> Sorry I had to drop out before the end, but the guys who pay the b= ills
> were hollering for me from across the hall.
>
> Jim
>
>
>

--Boundary_(ID_OaeAwUVPWOG8Z8NfnKH5+Q)--