[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] style probery
Hi Lofton. Sorry if the document status statement is unclear: I'll review and edit to remove any ambiguities. But as you say, this appears to be irrelevant to the matter of minting *private* namespaces. The status statement in NG document header now reads: [OASIS Naming Guidelines Part 1: Filenames, URIs, Namespaces http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.html ] Status: The OASIS Board has approved the Guidelines for use as of 2006-08-02; OASIS Staff is authorized to update the guidelines from time to time as needed. Cheers, - Robin Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink http://xml.coverpages.org/ http://xml.coverpages.org/newsletterArchive.html +1 972-296-1783 ----------------- On Wed, 15 Oct 2008, Lofton Henderson wrote: > At 11:15 PM 10/14/2008 -0400, Mary McRae wrote: > >> Ah sorry for the interruption. > > No problem -- better that we hear sooner rather than later, if something > might affect us. > >> I was responding to the OASIS example followed by the no firm rules . > > Right. I just meant to show Forrest how to put a de-referencable, > informative document at the URI of his private namespace. Sorry for the > confusion. > > (Robin and I did discuss a couple years ago what to put at the WebCGM > namespace; I studied RDDL and related initiatives, and concluded that "simple > informative" was a better idea at that time.) > > >> I ll make sure Robin updates the status this is an approved, and enforced >> document. > > Good. As I reviewed it, the doc was somewhat confusing as to its status and > force. > > Cheers, > -Lofton. > > >> From: Lofton Henderson [mailto:lofton@rockynet.com] >> Sent: Tuesday, October 14, 2008 10:55 PM >> To: mary.mcrae@oasis-open.org; 'Forrest Carpenter'; 'WebCGM' >> Subject: RE: [cgmo-webcgm] style probery >> >> >> >> At 07:18 PM 10/14/2008 -0400, Mary McRae wrote: >> >> OASIS *does* have a namespace policy here: >> <http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.html>http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.html >> >> >> It is my belief that we meet these requirements, for the WebCGM namespace. >> I have been using this document (of Robin's) for several years, and in fact >> had discussions with him on this exact topic -- to what should a namespace >> URI dereference? >> >> The particular question of Forrest is about *private* namespaces for >> application extensions to WebCGM's XML Companion File, in conformance with >> the XML Companion File extension rules of WebCGM 2.0 Chapter 4. >> >> Private means it is the property of Boeing, or Airbus, or SDI, or ... It >> is not a normative OASIS namespace defined in an OASIS Standard. >> >> I note that Forrest's question is, "what should be at the referenced >> application namespace?" (For *private* namespaces corresponding to >> application-specific extensions to XCF.) >> >> Your document says, for an OASIS-specified namespace, "ideally RDDL". That >> is not exactly a normative requirement, which is why the WebCGM namespace >> has an informative dereference document there (I went though all of this >> with Robin a couple years ago.) >> >> One other question. What is the status of the policy document? Early on, >> it says "this draft". (And following the link on "approved" in the Status >> section, it quotes Robin, "[requested] approval for trial implementation." >> >> -Lofton. >> >> >> >> >> >> From: Lofton Henderson >> [<mailto:lofton@rockynet.com>mailto:lofton@rockynet.com] >> Sent: Tuesday, October 14, 2008 5:21 PM >> To: Forrest Carpenter; 'WebCGM' >> Subject: RE: [cgmo-webcgm] style probery >> >> >> >> At 01:49 PM 10/14/2008 -0500, Forrest Carpenter wrote: >> >> [...] >> It after looking at the node-ns in the test suite it looks like the >> get/setAttributeNS will work. I do not understand what if anything needs to >> be at the namespace URI. If we use <http://sdicgm.com/>http://sdicgm.com is >> that sufficient? >> >> >> Have a look at the WebCGM namespace URI (sec 4.3): >> <http://www.cgmopen.org/schema/webcgm/>http://www.cgmopen.org/schema/webcgm/ >> >> There are no firm rules (that I'm aware of) for what needs to be at a >> namespace URI. Sometimes there is nothing (bad idea, IMHO). Sometimes >> informal like WebCGM. Then there are some more formal proposals, like >> RDDF. But no standards yet, AFAIK. >> >> ACTION: we need to update that dereferenced file at the WebCGM namespace >> URI, at least by the time of REC/OS. >> >> -Lofton. >> >> >> >> >> ---------- >> From: Lofton Henderson >> [<mailto:lofton@rockynet.com>mailto:lofton@rockynet.com] >> Sent: Saturday, October 11, 2008 5:42 PM >> To: WebCGM >> Subject: RE: [cgmo-webcgm] style probery >> >> >> >> All -- >> >> Reviewing this whole thread, it seems to me that get/setAttributeNS >> resolves Forrest's need without introducing any additional functionality >> (ApsAttr, etc). And it does so in the way intended for application >> extensions. To me, it sounds like Forrest's use case is such an >> application extension. (I'm still slightly unclear whether the particular >> application extension is formulated as a private instanciation of >> 'screentip' functionality, which Dieter correctly pointed out as something >> we try to avoid.) >> >> It would be nice if we could agree on a resolution (such as this) in the >> Wednesday telecon. >> >> If "agreed", then a couple questions might come up: >> >> 1.) should the spec have some additional explanation/examples of these >> features? (e.g. Forrest's could be an example); >> >> 2.) should the test suite have a test of get/setAttributeNS? (I think >> "yes".) >> >> Regards, >> -Lofton. >> >> At 11:30 AM 10/10/2008 -0400, Bezaire, Benoit wrote: >> >> "urn:schemas-microsoft-com:vml" xmlns:o = >> "urn:schemas-microsoft-com:office:office" xmlns:w = >> "urn:schemas-microsoft-com:office:word"> >> Hi Forrest, >> >> We have implemented get/set AttributeNS. I don't think a new API is needed >> since get/set AttributeNS is meant exactly for use cases like the one you >> describe. The code would look like this: >> >> powerObj.setAttributeNS("<http://acmeelectronics.com/>http://acmeelectronics.com","acme:state", >> "ON"); >> powerState = >> powerObj.getAttributeNS("<http://acmeelectronics.com/>http://acmeelectronics.com","state"); >> // will return "ON" >> >> The application developper needs to come up with a namespace URI. In this >> case, I came up with <http://acmeelectronics.com>http://acmeelectronics.com >> for example purposes. >> >> Benoit. >> >> ---------- >> From: Forrest Carpenter >> [<mailto:forrest@sdicgm.com>mailto:forrest@sdicgm.com] >> Sent: Friday, October 10, 2008 9:20 AM >> To: Weidenbrueck, Dieter; 'WebCGM' >> Subject: RE: [cgmo-webcgm] style probery >> >> All, >> >> >> >> What I am proposing is just a single metadata string, if we use get/set >> AttributeNS will this be supported by other vendors? >> >> >> >> Regards, >> >> Forrest >> >> >> >> ---------- >> From: Weidenbrueck, Dieter >> [<mailto:dweidenbrueck@ptc.com>mailto:dweidenbrueck@ptc.com] >> Sent: Wednesday, October 08, 2008 4:49 PM >> To: Forrest Carpenter; WebCGM >> Subject: RE: [cgmo-webcgm] style probery >> >> >> >> Forrest, >> >> >> >> good clarification. A couple of comments: >> >> >> >> We have a screentip attribute that could be used to display values like the >> ones you describe. >> >> If another attribute would exist that should be used to hold content for >> screentips, it would be in conflict with the original screentip attribute. >> >> If a NS attribute would be used, you could query the content via a script >> and set the content as a screentip in one single event handler. >> >> >> >> Anything that goes beyond this would require lots of definitions regarding >> the meaning of that content string, the values stored therein, the >> behavior, potential switches between the screentip attr and this one etc >> etc etc. >> >> I would use AttrNS instead and do the rest in a script. >> >> >> >> Regards, >> >> Dieter >> >> >> >> ---------- >> From: Forrest Carpenter >> [<mailto:forrest@sdicgm.com>mailto:forrest@sdicgm.com] >> Sent: Mittwoch, 8. Oktober 2008 23:42 >> To: 'WebCGM' >> Subject: [cgmo-webcgm] style probery >> >> All, >> >> >> >> Clarification: >> >> >> >> All a WebCGM viewer would be required would be to support the set/get the >> state style property it would require no graphical effect from the WebCGM >> viewer. >> >> An application that uses a WebCGM viewer could use this style property in >> response to a mouse over event to display information about a grobject such >> as voltage or to display a part number >> >> >> >> We could easily use JS variables to accomplish the same thing, but to me >> the code is simpler and more understandable if in response to a mouse over >> event the application can get the state style property using the ID >> returned in the mouse over function. If JS variables were used there would >> need to be a unique event handler for each grobject or a long if, if else, >> function to match the ID with the appropriate JS variable. >> >> >> >> The get/set AttributeNS could be used, but I do not completely understand >> the implications of this function. Are all compliant viewers required to >> support anyone s name space? We have not implemented this function in our >> viewer and I don t see any tests for this in the test suite. >> >> >> >> If no one else sees any value in this other than SDI, I will be happy to >> withdraw the request. >> >> >> >> Regards, >> >> Forrest >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]