All,
Here is a link to a site that has links to several sites on
regex code. We use the C++ code in windows and UNIX.
http://www.pcre.org/
Regards,
Forrest
From: Bezaire, Benoit
[mailto:bbezaire@ptc.com]
Sent: Monday, October 29, 2007
9:41 AM
To:
cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Regular
Expressions
Hi All,
I'd like for someone else to take this
action item. I don't think I'm the right person for this task (since I
feel there's no need for regex).
Regards,
Benoit.
From: Lofton
Henderson [mailto:lofton@rockynet.com]
Sent: Monday, October 29, 2007
10:11 AM
To: Bezaire, Benoit;
cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Regular
Expressions
At 09:13 AM 10/29/2007 -0400, Bezaire, Benoit wrote:
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 think it was Forrest or Don who claimed experience on a telecon. So to
them, about 'regex' freeware... available platforms/OS? licensing?
(description of what the interface looks like?)
-Lofton.
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.