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: [cgmo-webcgm] Regular Expressions


I don't know what kind of development effort this is (on Windows). I think regex is very popular on Unix (i.e., grep), but the same, I think, can't be said of other platforms.
 
I'd have to do some research on available libs. Then investigate the licensing.
 
I've provided detail explanation of what I believe our users want to do. If that was inaccurate, I suspect Dieter will say so. What I describe does not justify a regex implementation.
 
If everyone except me says we need regex, so be it. So far it's mostly been Stuart and I.
 
Benoit.


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Saturday, October 27, 2007 2:01 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Regular Expressions

My two cents in reply to both Benoit's and Stuart's comments...

At 02:43 PM 10/26/2007 -0400, Bezaire, Benoit wrote:
It looks like my email didn't get interpreted as I had planned...

In case I was unclear, I was not advocating any particular position, but rather trying to analyze and understand the possibilities.

 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?

Ummm... yes, all of it can be handled by 2.0, so these would be convenience methods.  SImilarly, the existing 'getAppStructuresByName' method is also a convenience method, as is the existing 'getAppStructureById'.  (More below.)

I was also trying to raise the question as you just asked:  why differentiate between regex matching in the 'name' ApsAttr and regex matching in the 'screentip' ApsAttr, or indeed in the 'content' ApsAttr (which latter we previously ruled out)?  (The use-case promoters could comment on this.)


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.

A substring is of course a simple regex.  Since regex-match software is alleged to be freely available, I'm unsure of the wisdom to try to fine tune whatever requirement we have so precisely (but I'm open to being convinced otherwise). 

For example, simple substring matching allows you to get all APS whose 'name' contains "ABC", but not all whose 'name' begins with "ABC".  The latter is amongst the sort of usage scenarios I have been hearing. 

If peoples' claims about regex freeware availability are accurate, then there is no/little more implementation cost for simple substring versus regex.  Am I missing some key point here?

At 01:42 PM 10/26/2007 -0700, Galt, Stuart A wrote:
For me it is a convenience method...  It is common for me to write scripts that
get a nodelist of all nodes that have a name that match my regular expression
then loop through each node performing some check or action.
 
It is not a life or death feature of 2.1 but it would mean that I don't need to drop
my function into all of my Q/A type scripts.

It seems that the question comes down to:  are these actions sufficiently common and the utility sufficiently widespread that we should offer them as standardized DOM interfaces, like we did with 'getAppStructuresByName' in 2.0.?

I don't know the answer.  If a lot of people are going to be doing the same thing as Stuart, I lean towards "yes".  (If "no", then maybe Stuart will post his 2.0-dependent convenience methods on the Web site for those who want them?)

And -- accepting the use case as Stuart described it -- I also lean towards the generalized solution suggested in one of Benoit's messages:  GetAppStructures( in string attrName, in string regex).  As I understand -- correct me if I'm wrong -- the implementation cost is not substantially different than the cost of the simpler and more restricted possibilities.

-Lofton.



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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]