OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cgmo-webcgm] WebCGM 2.0 XCF namespace question


Hi Lofton et al,

  Our intent is to use the base URI for the most current version. So
if you have webcgm 1.0, 1.1, 2.0, and 2.1, it would point to 2.1 for
now. When you create 3.0, it would then point to it. The reason for
insisting that we also create specific version directories is so that
we have a persistent URI for each and every spec.

There are three interwoven pieces in the production rules. The first
is required metadata, the second is file naming, and the third is
persistent IRIs. While file names for *documents* have a lot of
metadata embedded in the name, names for other filetypes are at the
TC's discretion as long as they are descriptive and unique. So
webcgm.xsd or webcgm.dtd or webcgm.cat are all perfectly legal.

Mary

On 6/3/05, Lofton Henderson <lofton@rockynet.com> wrote:
> My thoughts are at the end...
> 
> At 03:20 PM 6/3/2005 -0700, Cruikshank, David W wrote:
> >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?
> 
> Mary's reply makes my suggestion about "organizationally vague"  moot for
> now.  As long as we are progressing solely as OASIS standard, we should
> (must) follow the OASIS convention.
> 
> Altho' not REQUIRED to resolve to anything, personally I think it is nice
> to have a few words there, as SVG has done.
> 
> Presumably "/webcgm/" should be in the URL, and presumably its omission is
> a typo.  Whether or not we should specialize it for 2.0 is still an
> issue.  I don't know the arguments pro and con.  SVG chose NOT to do so, in
> going from 1.0 to 1.1 to 1.2 (*major* increment in functionality).  I'd
> like to understand why not, before taking a position on version-neutral
> versus version-specific.
> 
> Regards,
> -Lofton.
> 
> 
> 


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