OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]