[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] Text searching
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 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 -- 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'. 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). This is 1.0 legacy. It has not become an issue in the real world for 6 years. If it *must* be fixed, we should try our best to negotiate to fix it in a 2.1. Text search -- a non-requirement of 2.0 -- should not drag down the completion of the high-priority 2.0 requirements. -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]