[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] WebCGM 2.0 XCF namespace question
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]