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: Re[2]: [cgmo-webcgm] Text searching


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.

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. 

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.
We can't define anything that goes beyond this, because there is no
access defined to the contents of text elements using the DOM.

Regards,
Dieter

> -----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.
> 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]