[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.