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


Hello all,
 
If I am remember correctly I think the regex was to only be applied to the NAME and ID attributes. 
It is possible to write a javascript function that can return a list of nodes based on applying a regular
expression to any attribute (including name and id).  I was thinking of this feature as a "convenience 
function" and that queries for based on name and/or id would be the most common.  One thing we
will want to answer is what order are the results returned: depth first, breadth first, alphabetical,
any (up to implementer)?
 

--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656

 


From: Cruikshank, David W
Sent: Friday, October 26, 2007 10:55 AM
To: Lofton Henderson; Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Regular Expressions

I agree with Lofton.  It was restricted to id and name for regex searching (although id is questionable in my mind, if you use non-intelligent ids)
 
The other 2 groups (as Lofton split them out) can be covered by the script writer using the method Stuart contributed for searching content attributes for a string or by valued-added functionality.
 
Dave
 

Technical Fellow - Graphics/Digital Data Interchange
Boeing Commercial Airplane
206.544.3560, fax 206.662.3734
david.w.cruikshank@boeing.com

 


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Friday, October 26, 2007 10:48 AM
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]