RE: [cgmo-webcgm] style probery

[Robin Cover <robin@oasis-open.org>]

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