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'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. More inline...

Wednesday, May 3, 2006, 6:04:20 PM, you wrote:
> 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.
Hmmm. Isn't this an assumption? I could see it use this way when using
para/subpara on a raster; but that may not always be the case. 

Regardless, doesn't Chris' question still stand?

>> -----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.
I don't get to the same conclusion. The above wording doesn't even say
how to perform a search within RESTRICTED TEXT and APPEND TEXT
(without the 'content' attribute).

>> 
>>   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.
I'm not sure what you mean by syntax? I would expect this to be a
vendor feature (like the Search functionality in Web Browsers).

> 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.
That's sounds quite difficult to perform from a user's perspective.

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

Kind regards,

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