RE: [cgmo-webcgm] Proposed agenda for f2f meeting

[Lofton Henderson <lofton@rockynet.com>]

Addressing the points of Dave & Franck together...

As you recall, during the writing of WebCGM 2.0, the W3C Specification 
Guidelines [1] required us to include a conformance chapter [2].  One area 
that [1] requires to be addressed is extensibility, so we have such a 
section [3].  Within that section, we have a subsection about extensibility 
via profiles [4].

[1] http://www.w3.org/TR/qaframe-spec/
[2] http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-Conf.html
[3] 
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-Conf.html#webcgm_conformance_extensibility
[4] 
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-Conf.html#ext-profiles

That subsection is non-normative, but contains a start at the topic 
identified by Dave and Franck.  I recall that we had some discussions 
around these sections (and the conformance chapter in general) -- it raised 
some thorny questions (e.g., about DOM extensibility).  As I recall, we had 
a hard time nailing down a set of general rules about derived profiles (and 
that is the reason that we made this subsection "informative".)

[3] and [4] should serve as jumping off point for discussions about more 
comprehensive rules for cascading profiles.

Regards,
-Lofton.

At 08:12 AM 8/8/2007 -0700, Cruikshank, David W wrote:
>Franck,
>
>On your "other item".  I agree some work needs to be done on the rules for 
>cascading profiles (see 
>http://www.cgmopen.org/technical/cascading-profiles.html)  By the example, 
>it implies that a cascading profile can extend the WebCGM profile to add 
>functionality that   We recently talked about a cascading profile that 
>would allow more than one picture to satisfy a potential engineering 
>drawing requirement.  The referenced document doesn't seem to lay out the 
>exact rules.  Also, I know you had some concerns about the way the XCF was 
>specified for S1000D with branches excluded where they were not allowed in 
>S1000D (i.e. only grobject is allowed).  The derivation of XCFs should 
>probably be addressed more clearly, too, either in the spec or in the 
>rules for profiles.
>
>-----Original Message-----
>From: DULUC, Franck [mailto:franck.duluc@airbus.com]
>Sent: Wednesday, August 08, 2007 12:52 AM
>[...]
>On other item:
>We are from time to time talking about cascading profiles (ATA, ASD, ...). 
>I think the group should reach a consensus on that subject. Especially to 
>work on a set of rules for what is allowed or not in a cascading profiles. 
>You should say that this i writing a profile, but in my mind this is 
>slightly different. Rules have to be set: does WebCGM allows to its 
>cascading profiles allowing/dismissing primitives that are not 
>allowed/allowed in the profile? Can cascading profiles extends a list of 
>values for an attribute (e.g. compression modes). I think tha CGMOpen (as 
>a vendor community) has to be very clear, because behind that is the 
>implementation issue. For me this is no sense to allow in cascading 
>profiles something that the vendors will never implement because it is 
>cosly and addressing a nich community of users.
>Idea: it could be a document stating for each profile item what can be done?