[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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/25198/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]