Fw: New Catalog XML Draft

----- Original Message -----
From: "Kathryn Ginger" <address@hidden>
To: "John Caron" <address@hidden>
Sent: Monday, May 20, 2002 8:32 AM
Subject: Re: New Catalog XML Draft


> John
>
> Square brackets in DTD's generally indicate internal DTD declarations.
>
> Internal DTD rules override external DTD rules, but you can have both in
> the same document. Internal DTD declarations come after the external DTD
> call and between square brackets.
>
> Also my understanding is that most XML parsers will ignore "notation".
>
> And if you are thinking of moving from DTD's to schema, the notation
> concept is not in XML schemas as far as I can tell. So I would hesitate to
> use notation too.
>
> Katy
>
> On Fri, 17 May 2002, John Caron wrote:
>
> >
> > ----- Original Message -----
> > From: "Joe Wielgosz" <address@hidden>
> > To: "John Caron" <address@hidden>
> > Cc: <address@hidden>
> > Sent: Friday, May 17, 2002 1:07 PM
> > Subject: Re: New Catalog XML Draft
> >
> >
> > > John Caron wrote:
> > > ...
> > >  > ----- Original Message -----
> > >  > From: "Joe Wielgosz" <address@hidden>
> > > ...
> > >
> > > >>1) Don't restrict service types to known values. It is certain that
> > > >>people will want to add new service types, so the catalog format
should
> > > >>be extensible in this area.
> > > >>
> > > >>In order to prevent ambiguity (does "dods" equal "DODS" equals
> > > >>"distributed oceanographic data system"?) perhaps these types could
> > > >>somehow resolve to the url of the service's home page (e.g.
> > > >>DODS->http://unidata.ucar.edu/packages/dods). I don't know the most
> > > >>XML-savvy way to do this but perhaps the known mappings can be
included
> > > >>in the DTD?
> > > >>
> > > >>2) Same suggestion for metadata types.
> > > >>
> > > >
> > > > In both these cases, the XML thing to do is to use a URI as a unique
> > > > identifier. The options are eg:
> > > >
> > > > 1.  xlink:arcrole="http://unidata.ucar.edu/packages/dods";
> > > >
> > > > vs
> > > >
> > > > 2.  metadataType="DODS"
> > > >
> > > > Pros of 1: allows services to be added by anyone, URI optionally
point
> > to
> > > > explanation
> > > > Pros of 2: compact, explicitly documents allowable types
> > >
> > >
> > > John, flipping through my XML tome, I'm wondering if it wouldn't be
> > > appropriate to use the "notation" concept here.  Notations are
supposed
> > > to give the parser a clue how a particular entity should be
interpreted,
> > > which seems to be what we are doing with the metadataTypes and
> > > serviceTypes.
> > >
> > > Say the THREDDS DTD contained the following:
> > >
> > > <!NOTATION dods SYSTEM "http://unidata.ucar.edu/packages/dods";>
> > > <!NOTATION netcdf SYSTEM "http://unidata.ucar.edu/packages/netcdf";>
> > > <!ENTITY % standardMetadataTypes "dods | netcdf">
> > > <!ATTLIST metadataRef metadataType
> > >      NOTATION ( %standardmetadataTypes; ) #REQUIRED>
> > >
> > > What I didn't realize until last night is that it is possible for the
> > > client to extend the DTD in the actual document. So if i have a
protocol
> > > that is not on the THREDDS standard list, I could potentially produce
> > > the following catalog for my server:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <!DOCTYPE catalog SYSTEM
> > > "http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6.dtd";
[
> > >    <!NOTATION lgdp
> > >        SYSTEM "http://u-somewhere.edu/latest_greatest_data_protocol";>
> > >    <!ATTLIST metadataRef metadataType
> > >        NOTATION ( %standardMetadataTypes; | lgdp)
> > > ]>
> > > <catalog>
> > >     <service ID="myDODSService" type="dods" />
> > >     <service ID="myLGDPService" type="lgdp" />
> > >     ...
> > > </catalog>
> > >
> > > This means we keep our unambiguous standard list, and readability in
the
> > > file, but it is still possible for people to accurately catalog their
> > > data if they are using a "non-standard" (i.e. unknown to THREDDS)
> > > service. Of course it is a bit more complicated, but only for people
who
> > > are extending the standard types - for standard types it would be just
> > > like the 0.6 DTD from the data provider's p.o.v.
> > >
> > > What do you think?
> >
> > Well Id say i dont really understand it. What are the square brackets?
Does
> > that get added to the DTD? Its cool to be able to extend a Choice
> > declaration, but the complexity seems high. Im unclear as to whether the
> > NOTATION is actually seperate from the method of extending the Choice
list.
> >
> > NOTATION appears to be rarely used, I wonder if parsers will barf on it.
> >
> > >From the XML spec:
> > [Definition: Notations identify by name the format of unparsed entities,
the
> > format of elements which bear a notation attribute, or the application
to
> > which a processing instruction is addressed.]
> >
> > Your proposal does seem to fit in with the second meaning, but "XML in a
> > Nutshell" says "in practice, no common software actually supports this
> > scheme for indicating the element type". So Im a bit hesitant....
> >
> >
> >
> >
>
> --
> --------------------------------------------------------------------------
-
> Kathryn Ginger                                                  __o
> Meteorologist, Instructional Designer, Metadata Architect     _`\<,_
> Digital Library for Earth System Education (DLESE)           (_)/ (_)
> DLESE Program Center (DPC)
> University Corporation for Atmospheric Research (UCAR)
> UCAR/DPC                        Voice: 303-497-8341  Fax: 303-497-8336
> P.O. Box 3000                   e-mail: address@hidden
> Boulder, CO 80307 USA           http://www.dlese.org
> --------------------------------------------------------------------------
-
>
>
>