RE: [cgmo-webcgm] Text searching

["Cruikshank, David W" <david.w.cruikshank@boeing.com>]

This is scary....Dieter and I agree!...it turns out this is exactly what I said to Stuart right after I opened Ben's email!

Of course we don't have any guidence in the spec on what content might/should contain, but what Dieter points out is the way I've always viewed it.

Dave


Technical Fellow - Graphics/Digital Data Interchange
Boeing Commercial Airplane
206.544.3560, fax 206.662.3734  <-- NEW NUMBERS
david.w.cruikshank@boeing.com

-----Original Message-----
From: Dieter Weidenbrück [mailto:dieter@itedo.com] 
Sent: Wednesday, May 03, 2006 3:04 PM
To: 'Benoit Bezaire'; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Text searching

Benoit,

I think the example does not reflect the intentions of the authors.

It should be like this
>   (approx syntax)
>   BEGAPS 'myPara'
>    APSATTR 'content' 'Hello World';
>    ...
>    BEGAPS 'mySubpara'
>     APSATTR 'content' 'World';
>     ...
>    ENDAPS;
>   ENDAPS;

Hence the content attribute of the para would contain all the text of the para, whereas the attribute of the subpara woul contain the text of the subpara only.


> -----Original Message-----
> From: Benoit Bezaire [mailto:benoit@itedo.com]
> Sent: Wednesday, May 03, 2006 11:53 PM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: [cgmo-webcgm] Text searching
> 
> Hi,
> 
>   On the call today, Chris asked me the following question... Assume
>   we have:
> 
>   (approx syntax)
>   BEGAPS 'myPara'
>    APSATTR 'content' 'Hello';
>    ...
>    BEGAPS 'mySubpara'
>     APSATTR 'content' 'World';
>     ...
>    ENDAPS;
>   ENDAPS;
> 
>   And he does a text search on the string "Hello World", will he get a
>   hit, yes or no?
> 
>   I believe this to be an indirect way of asking/answering if
>   'subpara' is an inline or a block.
> 
>   If we say, yes there's a hit, then we've defined 'subpara' as
>   inline, if we say, no there's no hit, it's a block.
> 
>   What's the answer?
>   The specification says the following (for para)... The WebCGM
>   prescription for priority of text search matching is: 'para' with
>   matching 'content' (1st priority match); 'para' without 'content'
>   but with recognizable single-element RESTRICTED TEXT match (2nd
>   priority match); or, single-element RESTRICTED TEXT match, outside
>   of any 'para' (3rd priority match).
>   And for subpara: See 3.2.1.3, 'para'.
>   
>   In other words, it's not specified :(
I think that Chris wants to build a logical relationship between the attributes where there is none. You search ONE attribute at a time, not a combination of nested attributes.

> 
>   Chris made it relatively clear that if we want to have these APS
>   types in WebCGM 2, we need to improve how they are specified.
I agree that this is all underspecified, however, the entire search is still wide open, no syntax, nothing. 
The only way to get access is limited by the DOM functions, which don't allow you to access the RESTRICTED TEXT anyway if I remember this correctly.

So right now, whoever wants to search, can retrieve the content attribute of a para or subpara using the DOM, and he can then do whatever he wants to perform a search therein.

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.

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