The Linux Foundation


From The Linux Foundation

Revision as of 21:03, 30 July 2009 by Ptbrunet (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Agenda for 2009/07/07

Note: This set of notes is a work in progress. The meeting will be held a later date.

  1. Introductions if needed
  2. Approval of prior minutes - Corrections? Approval?
  3. LF: Open A11y news - Janina
    • Update on BSD relicensing.
    • Update on prior meetings between LF and Microsoft attorneys.
    • When will the LF board discuss the IA2 standard?
  4. Firefox - Marco Zehe
    1. Writing mode - some progress
    2. Auto generated text - no progress
    3. The Mozilla spec for the language attribute refers to IETF RFC 1766. The latest is 4646 and 4647 which obsolete 3066 which obsoletes 1766. Pending response from Alex.
    4. Document that valid values for text-position are: baseline (default), super, sub. Pending response from Alex.
  5. IA2 as an LF standard
    • Any changes since 1.0.2 will be released as version 1.0.3.
    • There items have been completed:
      • Added Microsoft attribution for trademarks.
      • Fixed some typos.
      • Added comment about using QI between IA2 interfaces but QS to IAApplication.
      • Deprecated the edit bar role.
      • The text for IAText::caretOffset has been updated to describe the behavior for hierarchical text objects.
      • Document that the flows from/to relation is helpful to tie text and non-text document objects together.
      • Change the IAText range description from "Range is from start of one word to the start of another word." to "The range provided matches the range observed when the application processes the Ctrl + left arrow and Ctrl + right arrow key sequences. Typically this is from the start of one word to the start of the next, but various applications are inconsistent in the handling of the end of a line."
      • Add reference to the IA2 text spec from the IAText section of the IA2 spec.
    • Remaining work items:
      • Add examples of the use of IAHypertext and IAHyperlink.
      • Move 3/26/2007 1.0.1 and 10/13/2008 1.0.2 IDLs into BZR.
      • Close out bugs that have been addressed.
  6. Text attributes spec
    • The spec should be final now and in sync with the current Firefox design. However, prior to a final review, we should wait until Firefox has completed all of the related work listed above.
  7. Object attributes spec
    • From Alex: Firefox exposes "table-cell-index" object attribute on table cell accessibles starting from Firefox 3.0. This object attribute returns index of the cell corresponding to the cell index used in IAccessibleTable interface (see for example, IAccessibleTable::childIndex). This object attribute is helpful to get cell index from cell accessible object. Could you consider to legalize this attribute and make it a part of IA2 specification?
      • This was agreed to last October and needs to be added to the spec.
    • When IA2_EVENT_TABLE_ROW/COLUMN_HEADER/DESCRIPTION_CHANGED are fired the AT doesn't know which row/column changed. Should we add four new table object attributes, i.e. row-description-changed-index, column-description-changed-index, row-header-changed-index, and column-header-changed-index?
  8. QI/QS
    • Comments on the list after the March 3rd meeting:
      1. From Andres: Pete and all: to clarify this note, I would explicitly say C++ object, where it says just object. The distinction is relevant because in COM literature, object is used also to refer to the entity that implements a group of interfaces, whether it consists of one or multiple C++ objects. The commonly used approaches to support QI using multiple C++ objects are known as aggregation or containment. So it would read something like:
        • Andres informed us that you can use QI even when the implementation use two or more C++ objects. The reason for using QS from an IAccesible is due to MSAA's implementation on Windows and not something inherent in the COM architecture. MSAA always gives you a proxy which requires using QS to get to non-MSAA interfaces. A client will have to QS to IA2 but then QI can be used for all the other IA2 interfaces even if they are implemented on a separate C++ object. The proposed text for QS/QI will be updated to take this into consideration.
      2. From Rob Gallo on the list: I think I understand the issue. If you use COM aggregation, it is possible to have an object who's various interfaces are implemented by separate objects. But in that case the object doing the aggregating appears to the outside world as supporting all interfaces and so COM identity rules are maintained. Without using aggregation it's not easy to spread interfaces across multiple objects. I'd also argue that even with aggregation this is not common to any but those who are very well versed in COM. QueryService does not require aggregation and hence is easier to implement. A discussion of COM Object identity rules is at:
    • How about if we say that QI must be usable between any of the set of IA2 interfaces and that typically this would require a single C++ COM object but if an implementation needed more than one C++ COM object then COM aggregation can be used to give the appearance of a single C++ COM object?
    • Two issues need to be fixed in the text:
      1. The following initial proposed text from Pete has an error, "If the SID is IID_IAccessible and the IID is IID_IUnknown, IID_IDispatch, or IID_IAccessible, then return the IAccessible for the IAccessible object, otherwise return E_NOINTERFACE." The requested interface should be returned, not always IAccessible.
      2. The text must make it clear that when you QI an object, the interface pointer that's returned needs to be for the same object.
    • Four open questions:
      1. Should the QS of IAccessible only respond to an IID of IID_IAccessible2 or should it respond to any of the IA2 IIDs?
      2. If IEnumInvariant is implemented, is it implemented on the same object as the rest of the IA2 interfaces?
      3. Will FF and Symphony respond without error based on this spec or will some bugs need to be written and a rollout plan put in place?
      4. Should IDispatch be allowed as an additional optional interface on the IA2 object?
  9. Eclipse
    • The implementation of IA2 in Eclipse 3.5 continues.
  10. Scope of IA2::uniqueID
    • Please review the following changes to the current text.
      Change one word in the first paragraph from "window" to "application", i.e. change:
      The uniqueID is an identifier for this object, is unique within the current window, and remains the same for the lifetime of the accessible object.
      The uniqueID is an identifier for this object, is unique within the current application, and remains the same for the lifetime of the accessible object.
      and change the last paragraph from:
      One means of implementing this would be to create a factory with a 32 bit number generator and a reuse pool. The number generator would emit numbers starting at 1. Each time an object's life cycle ended, its number would be saved into a resuse pool. The number generator would be used whenever the reuse pool was empty.
      to these three paragraphs:
      One means of implementing this would be to create a factory with a 32 bit number generator and a reuse pool. The number generator would emit numbers starting at 1. Each time an object's life cycle ended, its number would be saved into a reuse pool. The number generator would be used whenever the reuse pool was empty.
      Another means is to use the pointer of the accessible.
      Since some ATs need uniqueness within the machine, not just within the application, they use a combination of windowHandle and uniqueID.
  11. Lightweight IA2 objects
    • The description of IAccessible2 says, "This interface must always be provided for objects that support some portion of the collection of the IAccessible2 interfaces." However, objects that support IARelation or IAHyperlink should be lightweight with no need to support IAccessible2 or IAApplication. Are there any objections to this restriction?
  12. IAAction, IAHyperlink
    • The following two paragraphs are part of the description for IAHyperlink:
      An interesting use case is an image map where each area is associated with multiple actions, e.g. an image map of smart tags. In this case you would have to implement two levels of accessible hyperlinks. The first level hyperlinks would only implement anchor and anchorTarget. The anchors would all reference the image object. The anchorTargets would reference the second level accessible hyperlink objects. None of the IAccessibleAction methods would be implemented on the first level hyperlink objects. The second level hyperlink objects would implement the IAccessibleAction methods. Their anchors would also reference the image object and their anchorTargets would reference URLs or the objects that would be activated.
      This use case demonstrates that in some cases there is no need for IAccessibleHyperlink to derive from IAccessibleAction. As a result it may be removed in a later version of the IDL and it is suggested that implementations should not rely on the inheritance.
    This should be updated to take into consideration an offline comment from Jamie:
    My argument was that hyperlink anchors and actions are different concepts. Treating them as the same infers that a hyperlink can only have one action per anchor. I was arguing that they should be treated differently; i.e. that IAHyperlink should not derive from IAAction and there should instead be IAHyperlink::nAnchors. So this would require an additional method, not just the removal of the derivation from IAHyperlink.
  13. 64 bits
    • At some point we'll have to look at what needs to be changed for IA2 to be correct in both 32 bit and 64 bit environments. The 32bit world is also known as ILP32 where ints, longs, and pointers are all 32 bits. The 64 bit world is called LP64 where the longs and pointers are 64 bits. IA2 specifies all the integers as longs but they probably should have been specified as ints. There is a paper on ILP32, LP64.
  14. Types for IAValue
    • Should the VARIANT types for IAValue be limited to VT_I4 and VT_BSTR?

No progress on the following

  1. Proxy DLL
    • Jamie sent Pete his RC file so it can be compared to the one attached to bug 110.
    • When the 1.0.2 files are added to BZR, Pete to include the files needed to build the proxy DLL.
    • The process for building the DLL needs to be updated to cover the use of Visual C Express Edition.
    • That wiki page probably needs other changes.
  2. Access to smart tags
    • Symphony uses IAHypertext/IAHyperlink for smart tags. This seems reasonable because smart tags are very similar to links. They represent actionable text. IAHyperlink can represent more than one action which is common for smart tags.
      • One requirement is for links and smart tags to be differentiated. This can be done with an object attribute on the accessible that represents the link object. Are there any issues with that approach?
  3. IA2 issues from Calvin Gaisford, opened on the behalf of AIA.
  4. IA2 object attributes specification.
    • The Symphony and FF3 object attributes will be reviewed. The common attributes will become part of the IA2 object attributes spec and the spec will reference the FF3 and Symphony specific specifications. (The Symphony object attributes are not documented on any Symphony web site, but they'll soon be documented on the IA2 site.)
    • Pete to add a "display" attribute with CSS2 values.
  5. Items raised by NVDA last year need to be put on the agenda for an upcoming Open A11y meeting
    • These are generic issues that need to be solved for both IA2 and ATK/AT-SPI dealing with objects contained in documents and tables
    • See items 4 and 5 in the October 2nd 2007 minutes for the history.
    • This was discussed during the January 22 Open a11y meeting.
    • These should be reopened and discussed with Willie and Li Yuan at a call convenient to the US, China, and Australia.
  6. Wikipedia
  7. Developer Guide - Best practices document. We should start an outline for a best practices document. For starters it should define the following:
    • What events should be fired for each role and in what order.
    • What object hierarchy should be used. There are two today, a flat hierarchy as used in Symphony and a deeper hierarchy as used in Firefox. These two should be documented and in order to cut down on the proliferation of designs, future applications should attempt to use one or the other.
  8. FAQ
  9. Access to document revisions - from the ODF AccSC
    • This was reviewed by the AIA Interop group. The following issues were raised.
      1. What is the solution for non-text attributes, e.g. tables, images, charts, cells, spreadsheets?
        • From Oliver-Rainer Wittmann at Sun: Currently, the OOo Writer does not support change tracking for tables, table rows, table cells and anchored objects (text frames, graphics, embedded objects and drawing objects).
        • From Niklas Nebel at Sun: Recorded changes in spreadsheets are somewhat different from text documents: The spreadsheet cell structure only contains the current state. Changes are not part of a cell's content, but separate. Possible changes are:
          1. Content changes
          2. Inserting/deleting columns/rows
          3. Inserting sheets
          4. Moving cell ranges
          • Pending response from Niklas to some questions:
            1. Is there a link to the spec that describes those changes?
            2. What if a sheet is removed? Only insertion is mentioned.
            3. What is a cell range and what does it mean to move it? An example / use case would probably be enough to describe this.
        • The current proposed set of a11y interfaces and methods won't work for a spreadsheet. It will take some time to work through this. Pending requirements from applications developers, the team has agreed to attempt to work toward a spec that will work with a wider range of applications.
        • Pending response from Malte regarding requirements from OOo.
        • From Larry Weiss: UIA doesn’t have direct support for revisions (as such). But it does support “find” of “next” element with specific properties. So for compatibility, IA2 (and ATK) should expose a revision as a property of an element. As I recall, the proposal you referenced didn’t support all of the revision scenarios available in Word: comment only revisions; revisions with one or more comments; style revisions (font, color, bullet style, etc.); adding/removing/changing a link (or image). I don’t know of a list of all possible revisions supported by Word.
      2. How are comment only revisions handled?
        • Malte Timmerman doesn't think this is a feature of OpenOffice.
      3. Probably need more kinds of format changes besides insertion, deletion, and format change.
        • Malte wasn't supportive of this.
      4. Is more granularity needed for format changes, i.e. is it enough to just say there was a format change or should the kind of format change be indicated?
        • Malte said that as far as he knows this was discussed and the decision was to keep it at the current level of granularity.
      5. getSegmentAtOffset (singular) needs to be getSegmentsAtOffset (plural) because unlike links there could be overlapping insertions and deletions.
        • From Oliver-Rainer Wittmann at Sun: In OOo Writer there are no overlapping revisions/change trackings. The OOo Writer breaks a certain change tracking into corresponding pieces, if the user creates overlapping revisions/change trackings. Thus, revisions/change trackings are properly nested in OOo Writer. But nevertheless, there can be several change trackings at a certain cursor position. Thus, the proposed change is reasonable.
    • Once these issues are resolved Li Yuan, the committer for ATK/AT-SPI will develop a patch.

enum IA2RevisionType {
  IA2_REVTYPE_FORMAT_CHANGE  // The revision is due to any change in formatting attributes. 

typedef struct {
    enum IA2RevisionType type;  
    BSTR time;  ///< ISO 8601 format:  YYYY-MM-DDThh:mm:ss (eg 1997-07-16T19:20:21)
    BSTR author;
    BSTR comments;
} IA2RevisionInformation;

// Note: an object that implements IARevisionText must also implement IAText
// returns the number of segments available for the
// block of text represented by the IARevisionText object.
// this number is 1 based
get_segmentCount( long* count );
// returns a specific segment based on the index passed in
// the index is 0 based.
// no two indexes should return the same segment.
// any index >= 0, and less than the segment count should return a valid segment
// any index outside those bounds should set HRESULT to S_FALSE and return NULL
get_segment( long index,  IARevisionSegment** seg );
// returns a segment whose boundaries encompass the offset provided
// if there are no segments that correspond to the given offset, an error is produced
// offsets correspond identically to those used by IAText and IAHyperlink
get_segmentAtOffset( long offset, IARevisionSegment** seg );

// returns the bounding offsets of the segment within the IARevisionText/IAText object.
// the end offset is one past the last character in the revision text
get_bounds( long* start, long* end );

// returns a struct containing date/time, author, and comments
get_attributes( IA2RevisionInformation *revision_info );
// returns a set of name value pairs describing additional application
// specific attributes in the format "name:value;name:value"
get_extraAttributes( BSTR* extraAttributes );

[Article] [Discussion] [View source] [History]