RE: [cgmo-webcgm] Text searching

[Dieter Weidenbrück <dieter@itedo.com>]

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