OASIS Darwin Information Typing Architecture (DITA) TC

I'm in the process 
of cleaning up the SIDSC specializations and catalog.
 
My question is, what 
is our going-forward strategy for identifying DITA DTD/schema 
resources?
 
Should I use a 
public ID such as "-//OASIS//DTD SIDSC Component//EN"? Or should I use oasis 
namespace identifier in a URN, such as 
"urn:oasis:names:sc:sidsc:dtd:component.dtd:1.2"?
 
What are the 
guidelines for constructing public IDs?
 
The catalog shipped 
with the OT has schema URNs as a system ID; can a URN be used as a public 
ID?
 
Should every MOD and 
ENT file also have a publicID/URN? Or is it sufficient to provide a publicID/URN 
for the top-level shells and use relative URIs as system IDs to reference 
MOD/ENT files?
 
I suppose the URN 
would only be available for organizations with a registered namespace 
identifier, so most user local shells and specializations would not be able to 
use URNs. Aesthetically, a mixed approach for public identifiers would be 
unappealing, but harmless, I presume.
 
 
Thanks,
 
-seth
 

On 9/24/09 11:09 AM, "Park Seth-R01164" 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Thursday, 2009 September 24 11:17
> To: Park Seth-R01164; dita
> Subject: Re: [dita] strategy for identifying DTD/schema artifacts

 
> XML allows public IDs to be either URIs or SGML-style public ID
strings.

I wouldn't go so far as to imply that any URI can be
used as a public identifier.  Public IDs have a 
restricted character set--see my earlier email.

Also, using something like looked like a URL as a
public id would lead to confusion.  A user would
reasonably expect a URI entry in a catalog to be
used to map such an entry, but that wouldn't work.

paul

On 9/24/09 11:41 AM, "Grosso, Paul" 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Thursday, 2009 September 24 11:54
> To: Grosso, Paul; dita
> Subject: Re: [dita] strategy for identifying DTD/schema artifacts


> 
> Anyway, the TC practice is to use public ID syntax for public IDs.

Another nitpick:  Specifically, the TC practice is to use *formal*
public identifier (FPI) syntax for public IDs.

(I suspect this is what you meant to say).

paul

Wow! Thanks for all the information!

I created a wiki page for "best practices", so maybe it will be helpful
as new SCs come on board:
http://wiki.oasis-open.org/dita/BestPractices#preview

I've captured your suggestions in a section called "DTD/schema
development" and provided a link to the email thread, should we wish to
review the wisdom that led to our conclusion.

-seth

Are the PUBLIC id and URN naming conventions documented in the DITA 1.2
spec. somewhere?  If not, they should be.

   -Jeff

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Park Seth-R01164 [mailto:seth.park@freescale.com]
> Sent: Thursday, September 24, 2009 1:14 PM
> To: dita
> Subject: RE: [dita] strategy for identifying DTD/schema artifacts
> 
> Wow! Thanks for all the information!
> 
> I created a wiki page for "best practices", so maybe it will be
helpful
> as new SCs come on board:
> http://wiki.oasis-open.org/dita/BestPractices#preview
> 
> I've captured your suggestions in a section called "DTD/schema
> development" and provided a link to the email thread, should we wish
to
> review the wisdom that led to our conclusion.
> 
> -seth
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Park Seth-R01164 [mailto:seth.park@freescale.com]
> Sent: Thursday, 2009 September 24 11:09
> To: dita
> Subject: [dita] strategy for identifying DTD/schema artifacts
> 
> I'm in the process of cleaning up the SIDSC specializations and
> catalog.
> 
> My question is, what is our going-forward strategy for identifying
DITA
> DTD/schema resources?
> 
> Should I use a public ID such as "-//OASIS//DTD SIDSC Component//EN"?
> Or should I use oasis namespace identifier in a URN, such as
> "urn:oasis:names:sc:sidsc:dtd:component.dtd:1.2"?

For DTDs, use Formal Public Identifiers (FPIs) such as 
"-//OASIS//DTD SIDSC Component//EN".  

For XSDs, use URNs such as
"urn:oasis:names:tc:dita:spec:learning:xsd:learningContent.xsd"

> 
> What are the guidelines for constructing public IDs?

I would follow the example of the Learning and Machinery
cases for both DTDs and XSDs as can be seen in the OASIS
distributed catalogs.

> 
> The catalog shipped with the OT

[I assume that's just the catalog shipped as part of the DITA 1.2
spec.  In any case, use the DITA 1.2 distribution as the authority,
not the OT.]

> has schema URNs as a system ID; can a URN be used as a public ID?

Technically yes, as long as the URN doesn't contain characters
disallowed
in a public id--see http://www.w3.org/TR/REC-xml/#NT-PubidChar .
But it wouldn't be a Formal Public Identifier, and that's usually
what one wants to use for identifying such public entities, and
then the catalog would have to use a PUBLIC entry instead of a
URI entry, and the would just be confusing to most people.

So I'd recommend that you use URNs.

> 
> Should every MOD and ENT file also have a publicID/URN?

Yes.  This was an issue raised by Eliot quite a while ago, and
we agreed that you need to have an FPI/URN--and appropriate
catalog entry--for every file.

> Or is it
> sufficient to provide a publicID/URN for the top-level shells and use
> relative URIs as system IDs to reference MOD/ENT files?
> 
> I suppose the URN would only be available for organizations with a
> registered namespace identifier, so most user local shells and
> specializations would not be able to use URNs. Aesthetically, a mixed
> approach for public identifiers would be unappealing, but harmless, I
> presume.

One doesn't have to have a registered namespace identifier to 
use URNs.  Regardless, for local use, one can use just about 
anything that works.  Use of relative system identifiers is 
common, and a mix of URNs and public identifiers is okay.  
In fact, with appropriate use of a catalog, just about any 
identifier is okay in a local setting.

paul