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