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] 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]