RE: Re[2]: [cgmo-webcgm] Text searching

[Lofton Henderson <lofton@rockynet.com>]

Answering Dieter and Benoit together (more later, on specific technical 
details)...

At 10:59 AM 5/4/2006 +0200, Dieter  Weidenbrück wrote:
>Lofton,
>
>a small correction:
>
>There were two separate discussions:
>
>1. Text flow
>We decided not to pursue any modification to allow for some kind
>of text flow element. This would be a big chunk of work, as you
>mentioned in your email.
>There was no requirement for this.

I thought "requirement" was expressed, but not high enough priority to 
delay the primary DOM/XCF work.

(But my main point was ... if we get into nailing down search semantics of 
the APSs and attributes, it is inevitable that we'll have to consider other 
text related functionality that might be built on top of them, if only to 
avoid precluding future standardization such as flow-text, accessibility 
aids, etc).


>2. Text search
>This would be primarily a search syntax within the WebCGM fragment,
>plus some rules how text would and could be found, and what the
>behavior would be.
>This was a clear desire of the Navy, and it has been for the past
>6 years.

But it never made it into the 2.0 Requirements document.  Probably a case 
of "the squeaky wheel gets the grease".  (Sorry, I don't mean to imply that 
you're not vocal enough, Dieter, but without Navy's direct participation on 
the TC early on, the priority did not get elevated.)


>I think that the smallest change possible at this point in time
>would be a clarification about what the "content" attributes should
>contain, and that search is left up to the implementor using the
>DOM retrieval functions for this attribute.

My reply to Benoit yesterday was too pessimistic.  "Disaster" is not 
inevitable.  I suspect that we can answer Chris's questions, and at the 
same time avoid opening a slew of technical issues about search and other 
potential text-APS-based functionality.

We should continue to try, and hopefully Benoit is willing to retain the 
lead after the excellent start he has made.  (I'll make some technical 
responses to the thread later today.)

>We can't define anything that goes beyond this, because there is no
>access defined to the contents of text elements using the DOM.

It occurs to me (among other clarifications and explanations) that we could 
clarify 1.0's 3-step "search priority" wording, by more clearly presenting 
it as (non-normative) advice to applications that wish to build search 
capability on top of the para/subpara/content features.

-Lofton.


> > -----Original Message-----
> > From: Lofton Henderson [mailto:lofton@rockynet.com]
> > Sent: Thursday, May 04, 2006 1:23 AM
> > To: cgmo-webcgm@lists.oasis-open.org
> > 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.
> >
> >
> >