2006-126 Meeting Minutes

Roll Call

Duff Johnson - DJ, Chair, Document Solutions

Joe Clark, JC - Independent Accessibility Consultant
James Cole - JCole - Pitney Bowes 
Ferass Erayes  - FE - NetCentric Technologies
Mark Gavin - MG, Appligent
Loretta Guarino-Reid - LGR - Adobe Systems
Dick Herring - DH  Independent Accessibility Consultant
Bob  Martenengo - BM - Alternative Media Access Center
Greg Pisocky - GP -  Adobe Systems
Neil Soiffer - NS- Design Science
Melonie Zwack - MZ- Lockheed-Martin Corporation

Approval of PDF/UA 2006-125 Agenda

LGR / Soiffer

Approval of 2006-124 Meeting Minutes

Noted to correct Neil Soiffer's name. Apologies extended by the secretary. The change has been made.

Cole / Soiffer

Comment from the chair, Michael Everson subject of character encoding to take place at 4:00.

Report on Action Items

Action Items updated.

Select and review a specific "leaf"

Expansion of Abbreviations and Acronyms leaf.

From Page 872 of the PDF Reference Manual 1.6 Section 10.8.4 Expansion of Abbreviations and Acronyms

FE

LGR Share Ferass preference for specifying in structure rather than marked content sequence. Possible to have content that is not in the structure tree and still possible to fall back on marked content. Though there does not appear to be a compelling reason to do this.

RH - Could we use should/may language to encourage a preferred way to do things in lieu of formal depracation mechanisms.

MG Sure we can

DJ The level we are going to conform is principally through structure

FE One comment, by structure do you mean tags?

DJ Sure

FE Structure means both content and tags.

DJ If there is available an e property in marked content and that content is also tagged.

JC Please clarify the econtent

MG There is a dictionary with extra lookup info bured in the content stream. THe key in this case is the letter e and the value is what is to be worked on.

FE You can think of the e Property as Alt. It is a replacement for the contnet it encapsulates. Alt = first, expansion = second That's the way it behaves. It picks an order

LGR - A client can decide to do whatever it would like. These attributes are in the file.

JC - Sounds like a really nice thing to have, though you can over do it. Theere are problems. 1st occurance and Latin script language. What about Japanese where things can get really interesting? There appears to be disagreement on how this is done. THere is no consensus by the experts. In the majority of cases, you are using a finite well known set of well known abbreviations. This should be a user agent issue. The author need not be responsible for front loading all this inforamtion. SInce PDFs are databases, why can't the abbreviations be tucked away in a part of the document?  That's something that could be better than HTML that you can do in PDF.

NS: Is your suggestion that there's no markup required or are you suggesting that it should be marked as such but you would not have to provide the expansion?

DJ: There is definitely 2 issues: 1 appropriateness of applying an expansion in any given abbreviation. 2 Then there is mechanism - what tags, or perhaps a document specific attribute list?

JC: I would demarcate thems as 1) If you know there is an ab or acro do you mark it up and if you mark it up do you need an expansion?

LGR - No tag for abbreviation in PDF. It's an attribute.

JC - Maximalist approach - everything gets marked and is provided an expansion.

DJ: Why can't we just prescribe how it occurs rather than to ordain when it has to happen?

NS: It does seem as if the user agent should be able to figure it out.

LGR: It really is ambiguous.

JC: I am not denying. The way it has been approached has been problematical, I am trying to prescribe something better. FOr example what I would like to happen, I would not want to make it illegal to provide an abbreviation or acronym - for example DVD (which no longer has an expansion).

NS: Joe has hinted is there are cases where it needs to be marked up.

DJ: Is that appropriate content for the operational element of this discussion.

LGR: where it will show up is how we use shall vs. may.

DJ: From a mechanical point of view, let's preseume that we would never require (hypothetically) you would say you may. You would never use shall.

LGR: THe text sounds pretty universal.

MG: If you change the shall to a should.

JC: The way I would like to sya it is if the author believes the reader would be confused byt the content then the author would have to mark it up.

DJ: THis might be appropriate for the annex.

DJ: My suggestion is to take your suggestion (JC) and place it in the Core Concepts for PDF (informative) THis page is a bucket for the advisory information that we would include. You would simply edit the Annex B page and add it to that.

LGR: I wonder if we could place some sort of modify clause here, to the effect: To the extent which authors use abbreviations and acronyms, authors shall, blah, blah, blah....

Joe Clark updated the Annex B page per Duff Johnson's suggestion.

DJ: Mark for example suggested authors should rather than shall

LGR: 2 things, which of the two mechanisms should be used and the universality of how expansions should be applied.

LGR: THe language that Ferass provided is good, thought it implies that all abbreviations and acronyms

DH: Is there a conditional requirement structure -If / then

DJ: Yes, If expansion text is provided it shall be provided...

 LGR: Authors shall [existing copy] we jsut need to solve this problem of how to make it conditional.

DJ: In the case that expansion text is proved, then authors shall place... So what we are doing is ignoring eProperty with express to accessibility.

LGR: No it is not saying that, it says you should use the structure tag. THere is still this slingering problem that there is text in articfacts. I ahve no compelling reasons for believing abbreviation that show up in artivacts should have their expansions marked.

LGR: This would make much more sense if it were written inthe singular rather than the plural: In the case that expansion text is provided for an abbreviation or acronym

DH: Shouldn't it specify what structure tag is used?

NS: Author should be singular too. Shouldn't we specify the precise mechanism so the user agent

LGR: Today the screen readers never see this because in fact the User Agent is doing all the processing for them.

FE: We are not placing the expansion text in the structure tag...

DJ: I just fixed it, go ahead an refresh.

LGR: At some point we may want to think about we want to talk about the author. THis just talks about the PDF file.

DJ:  Yes, we have to provide it in file terms.

LGR: It's a language style issue...

FE: The abbreviation or acronym should be in its own structure tag.

NS: Yes that's better

NS: My personal prefernce is to drop the word "and" and make a separate sentence.

LGR: We haven't answwered Neil's question. At the very least we should allow it to be role mapped to SPAN.

FE: Can we recommend the approval of an abbreveiation tag?

DJ: There is a concept here of abbreviation or acronnym. We could make this tag to use.

LGR: I don't see a huge benefit from introducing a new tag. THe presence of the E Property makes this explicit. THere is no more infomation made avaialble - just another layer of heirarchy to navigate. THe other argument for not introducing a new tag is it inntroduces all sorts of backwards compatibility.

DJ: The idea of promoting an ease of use option

LGR: Whether we use span or appreviation

DJ: It seems to me we should affirm something....

NS: What about role mapping? Is this an extra complication?

Discussion ensued on how to use span tags, new tags, or new attribute on existing tags.

DJ: It is the value of the e Property which is the expansion text. If there was a dictionary for eProperties within span tags.

LGR: We could be taking about this , is there a more efficient way of represnting all these expansions?  There are a number of problems we are trying to solve. Are we losing sight of our goal?

JC: If you follow WCAG you only need to place the expansion on thefirst occurance, but if you jump in the middle a lookup table could be used.

DJ: We did not assert expansion should but in the case it is....

JC: Requiring an expansion on everything is actually worse than the HTML scenario...

LGR: If you are going to bother to tag them all, you might as well provide the expansion.

JC: No you might as well not. Life is too short.

RH: We can use should..

DJ: Do we suggest span, require span, or invent a new tag.

NS: Loretta what was your proposal in the case when you want to note it's an abbreviation and not expand it.

LGR: There's lots of metadata we could markup without the content.

NS: It would improve it because

 JC: Can you accept the use case of multiple examples of the abbreviation in the document.

LGR: My thought on the table is a more efficient case.

JC: Can't we just accept that it does happen.

LGR: I am agreeing that you shoudl mark them up and provide the expansion

DJ: So Loretta, you preference is for example 5 iterations of an acronym and forcing the vocalization of the complete expansion

LGR: All I am saying is, if you think it's importatnt to mark it up you shoudl explain to the client why it's different.

RH: Perhaps we could employ XMP

DJ: One of the immediate problems is that different acronyms won't have the same meaning for example Irish Republican Army and Individual Retirement Account.

LGR: My preference is to leave it the way it is. I am trying to explore the issue that Joe brought up. There is a potential space saving. This is one of these features that does not get heavily used because it's so labor intensive.

DJ: If we do as you're suggesting, we will have created scope for PDF files.

LGR: But you could do that and stick them back into eProperties too.

FER: How about this appraoch? If we had a table, but if we had an abbreviation and if we want a change then we would provide something in the eProperty.

LGR: we would have to somehow get that information to the screen readers which we do not have a way of doing it today.

JC: Dr for Doctor and Dr for drive using subscripts so the expansion maps to the proper one.

DJ: It's now 5 minutes to 5. It would be nice to encapsualte in some fashion the ideas just raised. I guess what I would recommend is to record the suggestion of Loretta and Ferass so that it is not lost and we could come back later. Or I could just encapsulate now.

Review and update "out of meeting" work assignments.

FER: I can write it on that page and people can respond to it as they will

LGR: That will work for me.

DJ: I want everyone to look at the working draft page. Note the existence of red text and the missing leaves. You want to take responsibility and complete these leaves, go ahead and add your name. What we don't have are some clear cut assignements going forward into the next meeting. Neal has one, Loretta is done, Melonie, Karen and Greg have one. The idea you commit to take 4 hours to perform.

NS: Since time is running out. Let's take a leaf and work on one.

MZ: I am interested in examing tables.

RH: I'll take media equivalents.

MG: How about PostScript X objects. There's a note in here, may want to disallow? Right off hand I would like to allow it. I will put some text in there.

JCole: I would like to go back and add some comments of my own regarding abbreviations. Navigation and document outline bookmarks. Section 5.2 sub 2 docuemnt outline.

DJ: 2 lines above the page level navigation assisgned to Angie Brooks.

MG: I did want to mention that if anybody had any questions they could call me.

FER: Duff I will look at the Content Structure Separation.

Wrap Up and Next Meeting

DJ: Thanks for taking on those assignments. Let's bring this to a close, and a reminder that the next meeting is set for September 6, 2006 3:00 - :00 pm Eastern time.

Adjourn

Meeting adjourned 5:07 pm 

Gavin / Soiffer