[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] Text searching
Wednesday, May 3, 2006, 7:22:52 PM, you wrote: > I want to read and reply to this thread in a little more detail, but > here are a couple of overarching observations... > At 06:31 PM 5/3/2006 -0400, Benoit Bezaire wrote: >>I'm seeing the emails coming in about this topic. And I have to state >>that I don't understand how people get to such an understanding of the >>feature by reading what is in the specification. > Nevertheless, I agree with Dieter, Forrest, and Dave about the > WebCGM 1.0 authors' intent. I don't disagree with the authors' intent. I'm simply saying there's no way an outsider (say Chris and I) can come to the same conclusion by reading the specification. >>[...] >> > I want to point out that I brought up this issue several times, it >> > is an important requirement of the Navy, but the group decided to >> > turn this down and to not define text search in WebCGM 2.0. >>Well, maybe it will have to be defined after all. > Dieter is correct -- we decided to postpone it, because it is a big > complicated topic, and we didn't want to drag down the 2.0 DOM/XCF > release for it. > IMO, it would be a disaster if we had to try to resolve this now in > 2.0 -- In that case, I don't want to have anything to do with this issue. > I predict it will take months for us to sort out and agree to a > complete set of detailed semantics for 'para', 'subpara', and > 'content'. I see that you are not optimistic about this. > In addition to defining text search, we will immediately run into > the issue of not precluding the other applications of these > APS/ApsAttr -- flow-text, accessibility/alt, etc. As happened at > Cologne (where we branched down the road of inventing and adopting > flow-text). What I don't understand is why WebCGM would have to define text search? Does HTML define it? SVG? PDF? No. Why would WebCGM have to be any different? What those specifications do define though, is what's a block and what's inline (i.e., semantics that can be used by an implementation). But it seems like people are not even willing to give that a try. > This is 1.0 legacy. Sure. > It has not become an issue in the real world for 6 years. In that case I must ask... is it even used in the real world? > If it *must* be fixed, we should try our best to negotiate to fix it > in a 2.1. As I've already said... someone else can take over the para/subpara issue. I'd like to see this specified but if I don't have any support, my time is better spent on other things (like future LC comments about the DOM). > Text search -- a non-requirement of 2.0 -- should not drag down the > completion of the high-priority 2.0 requirements. Well, it's a requirement to answer all LC comments, this being one of them. I won't be the one trying to convince Chris that this should remain under specified. -- Benoit mailto:benoit@itedo.com This e-mail and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. > -Lofton. >>-- >> Benoit mailto:benoit@itedo.com >> >>This e-mail and any attachments are confidential and may be protected >>by legal privilege. If you are not the intended recipient, be aware >>that any disclosure, copying, distribution or use of this e-mail or >>any attachment is prohibited. If you have received this e-mail in >>error, please notify us immediately by returning it to the sender and >>delete this copy from your system. Thank you for your cooperation. >> >> >> > Regards, >> > Dieter >> >> >> >> So here are some thoughts... >> >> I see RESTRICTED TEXT as a block. >> >> I see APPEND TEXT as an inline. >> >> >> >> So regardless of para/subpara/content... If 'Hello' is in a >> >> RESTRICTED TEXT and 'World' in a child APPEND TEXT, a search on >> >> "Hello World" would generate a hit. Anyone agrees with me? >> >> >> >> I would be tempted to use the same logic on 'content'. I.e., if >> >> 'content' is specified on a para, it's a block. If it's specified on >> >> a child subpara, it's an inline. However, I don't know if the >> >> current search functionality provided by vendors adopts the same >> >> logic?! >> >> >> >> I'm still waiting for more information from Chris about this, but >> >> why not get the conversation started right away within the group? >> >> >> >> Cheers, >> >> >> >> -- >> >> Benoit mailto:benoit@itedo.com >> >> >> >> This e-mail and any attachments are confidential and may be >> >> protected by legal privilege. If you are not the intended >> >> recipient, be aware that any disclosure, copying, >> >> distribution or use of this e-mail or any attachment is >> >> prohibited. If you have received this e-mail in error, please >> >> notify us immediately by returning it to the sender and >> >> delete this copy from your system. Thank you for your cooperation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]