[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Re[2]: [cgmo-webcgm] WebCGM 2.0 XCF namespace question
Hi everyone, There are two different issues here - one is an actual, resolvable URI that will result in accessing either the schema or a RDDL file. In this case, we must insist that such a URI be persistent and always access the same file. If, on the other hand, you want something that won't be resolved by the processing application, then www.cgmopen.org/webcgm would do the trick. We do not want years placed in the namespaces; I don't see any difference between a year and a version. It's fairly common practice that minor releases are backwards-compatible; major releases indicate that previous datasets will no longer validate against the new schema. So if you set up the namespace as www.cgmopen.org/webcgm/v2 you could encompass the *latest version* of any 2.x release. When (if) a v3 is released, a new namespace would indicate that this version is not compatible with 2.x data and those applications would still access the 2.x version. Hopefully that makes sense? Mary On 6/6/05, Benoit Bezaire <benoit@itedo.com> wrote: > I don't really like it, please see inline... > > Saturday, June 4, 2005, 4:26:20 AM, Dieter wrote: > > DW> Dave, > > >> She may have meant www.cgmopen.org/webcgm/v2.0? If we intend to > >> process through both OASIS and W3C, this might be the best approach. > DW> I'm in favor of this approach. Reasons: > > DW> - it points to CGM Open ;-) > DW> - it has the version number rather than a year > DW> (just in case we have two versions in one year) > FYI, groups like SVG WG do not change their namespace when a new > version of the specification is released: SVG 1.0, 1.1, 1.2 all have > the same namespace (the SVG 1.0 namespace). > > If an application is parsing an HTML + SVG document: > <html xmlns="http://www.w3.org/1999/xhtml";> > <body> > <svg xmlns:svg="http://www.w3.org/2000/svg"; ... > </svg> > </body> > </html> > > What I care about, is to know that <svg> is in a different namespace > than <html>... I.e, the parser will tell me that <svg> is not in the > default XML namespace but in the "http://www.w3.org/2000/svg";. > > If we put the version number in the URI it means that _all_ > applications reading those files have to be updated each time an > update is done. I don't think that's a very good thing. Example, we > still want to have WebCGM 2.0 application reading WebCGM 2.1 files. > They may not be 100% correct, but they should still work to a certain > degree. By inserting the version number, I think we're assuring > ourselves that they will _not_ work. > > When my applyCompanionFile code looks to see if an element or > attribute is part of the WebCGM namespace (a temporary namespace I've > created), it compares the strings, if you change the string, you break > the code. BTW, I believe this to be common in all XML parsing > applications. > > I think http://www.cgmopen.org/2005/webcgm/ is better. And this would > not change unless the fundamentals of XCF change completely. > > DW> One question: > DW> This is the namespace for the XML Companion File only, right? > Yes. > > DW> We decided that the version of the XCF is independent from the WebCGM > DW> version to allow for updates of the DTD without having to change > DW> the profile (Cologne). > Hmmm, there were some more talks after that... something along the > lines of "how can we update the DTD without updating the profile when > the DTD is part of the profile". > > DW> So what version number do we use for the DTD? 1.0? > I don't really care, but I think the decision was to start at 2.0 (to > align it with the specification). BTW, this got me thinking that W3C > may require a schema instead of a DTD for us to obtain REC. If that is > the case, this will really slow us down. > > -- > Benoit mailto:benoit@itedo.com > > DW> Regards, > DW> Dieter > > >> -----Original Message----- > >> From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com] > >> Sent: Saturday, June 04, 2005 12:20 AM > >> To: CGM Open WebCGM TC > >> Subject: [cgmo-webcgm] WebCGM 2.0 XCF namespace question > >> > >> > >> I've been in contact with Mary McRae at OASIS regarding our namespace. > >> > >> Here's the question I posed: > >> > >> This is really to define the unique namespace to be used in > >> conjunction with WebCGM 2.0 XML Companion Files. It does not > >> need to be resolvable, just unique along with the defnitions. > >> > >> It appears W3C has a standard that looks like: > >> http://www.w3.org/yyyy/area where yyyy is the year and area is > >> the technology. For example the SVG namespace is > >> http://www.w3.org/2000/svg and there is something similar for the > >> XML namespace. > >> > >> Has OASIS put any thought into standardizing the format of > >> namespace definitions? > >> > >> As CGM Open we could adopt a W3C form > >> (http://www.w3.org/1999/webcgm) or an Oasis form > >> (http://www.oasis-open.org/webcgm) or, if we process WebCGM 2.0 > >> through both organizations it might make more sense to use > >> something like http://cgmopen.org/webcgm. > >> > >> Mary responded: > >> > >> While we do not yet have a final version of the artifact > >> identification document done yet, I'm confident that you can use > >> "docs.oasis-open.org/webcgm" > >> > >> Depending on your requirements, you may want to always point to > >> the most recent version of webcgm (which the above namespace > >> would provide) or more specifically, > >> "docs.oasis-open.org/webcgm/v2.0" to > >> get to the 2.0 release. > >> > >> Lofton then responded: > >> > >> Having seen Mary's replies, and pondered the impact of possible > >> OASIS-W3C effort, I wonder if we shouldn't go for something > >> functional but organizationally vague for now. By "for now", I > >> mean for an expected 2nd CD publication, in early July timeframe. > >> > >> How about if we use this for now? > >> > >> http://www.cgmopen.org/2000/webcgm > >> > >> Mary then responded: > >> > >> OASIS specification documents, specification file names and IRIs > >> must conform to OASIS policy per the new TC Process. The work is > >> being conducted within OASIS and under OASIS process rule. While > >> not exactly docs.oasis-open.org, cgmopen.org is an OASIS site. If > >> the work moves forward jointly, www.cgmopen.org/v2.0 can be used; > >> otherwise docs.oasis-open/cgmopen/v2.0 would be the proper place. > >> > >> Me again: > >> > >> She may have meant www.cgmopen.org/webcgm/v2.0? If we intend to > >> process through both OASIS and W3C, this might be the best approach. > >> > >> Thoughts? > >> > >> thx...Dave > >> > >> > >> Technical Fellow - Graphics/Digital Data Interchange > >> Boeing Commercial Airplane > >> 206.544.8876, fax 206.544.9590 > >> david.w.cruikshank@boeing.com > > > > -- Mary P McRae Manager of TC Administration, OASIS mary.mcrae@oasis-open.org voip: 603.232.9090
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]