[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] regex in 'name' and 'apsid' addressing
Lofton, The purpose of a regex instead of specifying a unique ID or a non-unique name is to select a certain list of objects (grobjects, paras, layers)that match the regex. Such a selection could be returned by a DOM call, however, it could also be used to address these objects directly, e.g. using the fragment. In this case, we would already have a list of behaviors that we could apply to this selection. Example: Highlight all objects whose name contains "bolt". So whereever we can specify a name now we should be able to use a regex in the future. In those cases where we use an ID now we have to be more careful, because the regex could potentially return more than one object. Needs a bit more consideration. Hence the DOM is affected, the fragment as well, the linkURI. This will also enable users to address objects by using a regex from an HTML anchor. Regards, Dieter -----Original Message----- From: Lofton Henderson [mailto:lofton@rockynet.com] Sent: Dienstag, 11. September 2007 01:26 To: cgmo-webcgm@lists.oasis-open.org Subject: [cgmo-webcgm] regex in 'name' and 'apsid' addressing From the last telecon... At 08:07 PM 9/5/2007 +0000, david.w.cruikshank@boeing.com wrote: >Download >Document: >http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/2 >5198/20070905_WebCGM_TC_Telecon_minutes_r1.pdf > We were talking about generalizing object addressing, by allowing regular expressions (regex) in 'apsid' and in the 'name' ApsAttr. Here is a quote from the minutes... >Dieter also suggested that we could expand the getAppStructureByName >and getAppStructureById methods to include regular expression pattern >matching on the name APS attribute. An example would be to access all >switches who's name begin with "A" ("A*") so that they could all be >turned off. He also implied that doing this could improve performance >if we could act on a nodelist to set attributes instead of individually >setting them. >Is there vendor commitment? >In general, it appeared that the vendors would implement this as a >vendor specific interface and not as a standardized method. Dieter >offered to document his proposal for expansion of the >getAppStructurebyName and get AppStructureById methods. >Action / Responsible / Due >White paper describing >applying regular expressions >to the name APS attribute for >searching / Dieter / 12 Sep 2007 In general, I think it is a potentially useful and interesting extension for 2.1. I do have some questions and thoughts about its scope and nature. First question, about scope, and this really applies to a lot of 2.1 stuff that we're talking about: in which of three possible functional areas should the feature be defined and usable in some form? 1.) DOM interface; 2.) In the fragment definition: In a WebCGM instance itself (i.e., should regex be allowed in 'apsid' and in 'name' ApsAttr in WebCGM instances), and in fragments for example in external XHTML content that address into a WebCGM. 3.) In XCF. Second question: Is there an issue with the char-repertoire of 'name' [1], that it allows meta-characters that are significant to regex to appear within names? (By the way, we have already reserved the 1-character name "*", as it appears in the special-form fragment "id(*,clearHighlight)" -- fortunately, that is regex-compatible for an expanded regex capability.) [1] http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-IC.html#webcgm_ 3_1_1_3 I don't know the answer to this question yet. I suspect that we could come up with a scheme that uses meta-character escaping (typically "\" in regex, if I recall), but it will need some careful definition. It's much easier for 'apsid', which has a much more restricted character repertoire [2]. [2] http://www.w3.org/TR/2004/REC-xml-20040204/#sec-common-syn It is also possible that, instead of just trying to drop regex syntax into the current fragment definition, we could expand the fragment syntax by adding new keywords and structure, e.g., name( regex(myNameWithRegexStuff), myObjBehavior). (It potential creates backward-compatibility clash, but on the other hand there probably isn't much content out there where someone has built an object name that is framed with "regex(....stuff....)"). All for now, -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]