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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Re: [dita] Comment on DITA 1.1: Defining and using normative URIs for allDITA-Supplied Schema Components


Now that Eliot is back, I'm rolling up some discussions that we have had
regarding URIs for the Schema components.

Here are the highlights:
  - TC approved the following item on May 1, 2007
       Defining and using normative URIs for all DITA-Supplied Schema
Components
      http://lists.oasis-open.org/archives/dita/200704/msg00052.html
  - Eric S. has a concern about using a URL the define the normative value
for the Schemas.
      - Applications mot using catalogs may make request to the URL to
OASIS web server.
  - Paul G.  suggests using URNs to reference the schemas. - Eric and Eliot
concur.
  - Eric S suggests adding a version number to the URN scheme.

 - URN Schema for schema components
urn:oasis:names:tc:dita:xsd:schema-or-module-name.xyz:1.1

 - One topic in the Architectural spec would have to be updated.

Eric

Eric  - 05/04/2007
    What is OASIS's policy about hosting XML Schema  at the URL as defined
in the schemas?  I'm am aware that W3 website is running into issues that
applications out-in-the-wild a making requests to URLs rather than making
use of catalogs.  I think that we should not make the schemas accessible
via the web.

Paul G. - 05/04/2007
Another solution would be to use URNs to reference the schemas.
That would be more parallel to the DTDs' use of FPIs and would
address your concern. ... There is some precedence
for this in OASIS already, viz.:

 The namespace name defined by this OASIS Standard is
 "urn:oasis:names:tc:entity:xmlns:xml:catalog". The public
 identifier for XML Catalogs is "-//OASIS//DTD XML Catalogs V1.1//EN".
...
Granted, that's an example of using a URN for a namespace,
but it does show that OASIS has does some things with URNs.
We could develop URNs of the form
             urn:oasis:names:tc:dita:xsd:schema-or-module-name.xyz
...

Of course, all this URN business would be to ensure that tools
that don't use catalogs won't hit the OASIS server, but it won't
help them work properly.

Eric
     I agree that we would use URNs instead  of URLs in the catalog entries
and in the modules.  It removes any ambiguity that the schemas may be
available via a URL on the web. I think that we should  also add a version
number to the URN value. For instance,
urn:oasis:names:tc:dita:xsd:highlightDomain.xsd:1.1
        From Paul G.
   >The analogous XSD module contains:
   >
   >  <xs:include schemaLocation="highlightDomain.xsd"/>
   >
   >and there is no corresponding catalog entry.
   >
   >I'm suggesting that the XML Catalog add an entry something like:
   >
   >  <uri name="urn:oasis:names:tc:dita:xsd:highlightDomain.xsd"
   >          uri="highlightDomain.mod"/>
   >
   >and the above quoted line in a schema module be changed to:
   >
   >  <xs:include
   >schemaLocation="urn:oasis:names:tc:dita:xsd:highlightDomain.xsd"/>

Eliot - 05/08/2007

I think that we should us URNs rather than URLs unless there is an
intent to serve the schemas from the URLs. Using URNs will leave things
as they are for DTDs, that is, you have to use a catalog to map the
public IDs.


Eric - 05/08/2007

From Eliot:
>>I think that we should  also add a version number to
>> the URN value. For instance,
>> urn:oasis:names:tc:dita:xsd:highlightDomain.xsd:1.1

>urn:oasis:names:tc:dita:1.1:xsd:highlightDomain.xsd

My thought was the same as yours for the location of the version number,
but looking at RFC3121/RFC3986...they have the version number at the end.
Personally, I don't have a preference where the version should be.   I
assume that we should stick to the representation that is defined in the
RFC.

Examples from the RFC:

urn:oasis:names:specification:docbook:dtd:xml:4.1.2
urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1


Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Blue Pages (Internal)

"Transparency and accessibility requirements dictate that public
information and government
transactions avoid depending on technologies that imply or impose a
specific product or
platform on businesses or citizens" - EU on XML-based office document
formats.


                                                                           
             "Grosso, Paul"                                                
             <pgrosso@ptc.com>                                             
                                                                        To 
             04/24/2007 06:26          "DITA TC list"                      
             PM                        <dita@lists.oasis-open.org>         
                                                                        cc 
                                                                           
                                                                   Subject 
                                       [dita] Comment on DITA 1.1:         
                                       Defining and using normative URIs   
                                       for all DITA-Supplied Schema        
                                       Components                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




[EricS, Eliot, and I have been discussing this topic that
I am now putting forward as a comment on DITA 1.1.  paul]


All the DITA 1.1 DTD modules have official formal public
identifiers that are used to reference them.  For example,
topic.dtd references programmingDomain.ent via:

<!ENTITY % pr-d-dec     PUBLIC
"-//OASIS//ENTITIES DITA Programming Domain//EN"
"programmingDomain.ent"                        >
%pr-d-dec;

The public identifier can be used in a catalog to point to
wherever the desired module may really be.

However, the DITA 1.1 XSDs do not parallel this situation.
We have only defined URIs for the top level shells, and the
XSDs have xs:includes that refer directly to modules; e.g.,
topic.xsd references programmingDomain.xsd via:

  <xs:include schemaLocation="programmingDomain.xsd"/>

While it is true that one can put in a catalog entry to map
the URI "programmingDomain.xsd" to something, this tends to
be confusing to users, and the lack of more "official" URIs
for the modules doesn't seem to parallel the DTD situation.
It makes is harder for users who need to remap the URIs to
another location for their purposes.

We should do for XSDs something similar to the DTDs.  We should
define normative OASIS URIs for each schema-related file in
the distribution, the xs:imports and xs:includes in all the
files should use these normative URIs, and the distributed
catalogs should have entries that map these URIs appropriately.

This shouldn't change anything user-visible except for those
advanced users who are already trying to remap URIs via
catalog entries.  I think we should do this in 1.1.

paul




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