[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[4]: [cgmo-webcgm] WebCGM 2.0 XCF namespace question
Hi Mary, Please see inline. Monday, June 6, 2005, 9:34:44 AM, Mary wrote: MM> Hi everyone, MM> There are two different issues here - one is an actual, resolvable MM> URI that will result in accessing either the schema or a RDDL file. In MM> this case, we must insist that such a URI be persistent and always MM> access the same file. Understood. MM> If, on the other hand, you want something that MM> won't be resolved by the processing application, then MM> www.cgmopen.org/webcgm would do the trick. We do not want years placed MM> in the namespaces; I don't see any difference between a year and a MM> version. Are you not mixing up the XML namespace with the schema location? Is there a rule stating that the XML namespace must be host to the schema? The XHTML namespace, http://www.w3.org/1999/xhtml, doesn't point to a schema or DTD? Neither does SVG, http://www.w3.org/2000/svg. Even the XML 1.1 namespace is still, http://www.w3.org/XML/1998/namespace. BTW, the year (in the markup namespace, not schema location) is simply referencing the year the first specification became a standard. Since the XML namespace doesn't change for every update of the spec, having the year in the XML namespace is not a problem. MM> It's fairly common practice that minor releases are MM> backwards-compatible; major releases indicate that previous datasets MM> will no longer validate against the new schema. As I said, this thread was speaking to the XML namespace of the WebCGM 2.0 syntax, not the schema location. MM> So if you set up the namespace as www.cgmopen.org/webcgm/v2 you MM> could encompass the *latest version* of any 2.x release. When (if) MM> a v3 is released, a new namespace would indicate that this version MM> is not compatible with 2.x data and those applications would still MM> access the 2.x version. We understand that the schema location URI should be version aware. MM> Hopefully that makes sense? Let me split the question in two: - Is there an OASIS convention regarding the form of an XML namespace URI? - Is there an OASIS convention regarding schema location of its specification? Kind regards, -- Benoit mailto:benoit@itedo.com MM> Mary MM> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]