RE: [cgmo-webcgm] Regular Expressions

["Bezaire, Benoit" <bbezaire@ptc.com>]

It looks like my email didn't get interpreted as I had planned...

 

ALL of the use cases I listed below can be retrieved with a WebCGM 2.0 viewer (with some JS). If we add more APIs, they would be convenience methods only. This raises the question: if the group agreed to provide an example for 'content', why would 'id', 'name' and 'tooltip' be different?

 

Additionally, the logic in the list below (with respect to id/name) is the following: does the attribute value contain a given substring? If that's all that is needed, do we need to introduce regular expressions for that? I would argue no. However, if people feel there is a need for additional logic, please say so.

 

Regards,

Benoit.

---

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Friday, October 26, 2007 1:48 PM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: Re: [cgmo-webcgm] Regular Expressions

At 01:30 PM 10/26/2007 -0400, Bezaire, Benoit wrote:
> [...] 
> I'm starting work on my regex 
>   action item. I'm slightly confused though. I'm confused by what is needed. 
>   Once again, we are short on requirements. What I have to go on is "regex APS 
>   addressing: via regex in 'apsid' and/or 'name'.
>  
> That one line description however, doesn't seem to match our 
>   user requirements all that well.

Hopefully Dieter can 
jump in here.  As I recall, he was talking about this after we decided that 
text search -- content and/or RT elements -- would be "value-added" for viewers, 
as opposed to new standardized DOM entries.

More comments 
embedded...

> So, 
>   here are our user requirements:
> - finding 
>   all APS (grobject, para, subpara)
> - finding 
>   APS which have a given substring in its 'id'.
> - finding APS which have a given substring in its 
>   'name'.
> - finding APS which have a 'name' 
>   attribute.
> - finding APS which do not have a 
>   'name' attribute.

The above are all handled with regex on 
name or id.

> - finding 
>   APS which have a tip equal to a given string.
> - finding APS which have a tip different than a given 
>   string.
> - finding APS which have a tip 
>   containing a given substring.
> - finding APS 
>   which have a tip.
> - finding APS which do not 
>   have a tip.

All handled via regex on 'screentip'.  
So you raise a good point -- is this to be viewer "value-added", as we decided 
for the 'content' ApsAttr?  Or is it to be standardized in new DOM 
functionality.  (And if the latter ... how does this differ from 
'content'.)

> - finding 
>   APS which have a given attribute equal to a given string.
> - finding APS which have a given attribute different than a 
>   given string.
> - finding APS which have a 
>   given attribute containing a given substring.

Same 
comment, generalized to "given attribute" instead of 'screentip'.  (And how 
does "given attribute" differ from 'content', as far as our decision process is 
concerned?

> We also 
>   have some text searching requirements, but I think the group has agreed to 
>   leave that viewer dependent.

As I understood, the 
decision was based on text search that comprised searching 'content' ApsAttr 
and/or the strings within RestrText elements.  Do I understand that 
decision correctly?

> I'd 
>   first like to know what people had in mind when talking about regex? Was it 
>   id/name only? Or something along the lines of what is seen 
> above?

When Dieter proposed it in lieu of text searching 
(which we decided against), I thought it was restricted to 'name' and possibly 
'apsid' as well.  Dieter?  (Others?).

-Lofton.