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


Wednesday, May 3, 2006, 7:22:52 PM, you wrote:
> 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 don't disagree with the authors' intent. I'm simply saying there's
no way an outsider (say Chris and I) can come to the same conclusion
by reading the specification.

>>[...]
>> > 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 --
In that case, I don't want to have anything to do with this issue.

> 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'.
I see that you are not optimistic about this.

> 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). 
What I don't understand is why WebCGM would have to define text
search? Does HTML define it? SVG? PDF? No. Why would WebCGM have to be
any different? What those specifications do define though, is what's
a block and what's inline (i.e., semantics that can be used by an
implementation).

But it seems like people are not even willing to give that a try.

> This is 1.0 legacy.
Sure.

> It has not become an issue in the real world for 6 years.
In that case I must ask... is it even used in the real world?

> If it *must* be fixed, we should try our best to negotiate to fix it
> in a 2.1.
As I've already said... someone else can take over the para/subpara
issue. I'd like to see this specified but if I don't have any support,
my time is better spent on other things (like future LC comments about
the DOM).

> Text search -- a non-requirement of 2.0 -- should not drag down the
> completion of the high-priority 2.0 requirements.
Well, it's a requirement to answer all LC comments, this being one of
them. I won't be the one trying to convince Chris that this should
remain under specified.

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


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