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] URI scheme for TC subcommittees

Here is the follow-up note that I agreed to send out during today's DITA TC call.


I think some sort addition to the DITA TC’s URI naming convention along the lines suggested by Eric is a good idea.


I wonder if using TC sub-committee names is the right way to organize this in the long run. Sub-committee’s will come and go, but if the specializations they produce are useful, the specializations may have a longer life then the sub-committee. And we may want to push some specializations that are developed by the TC as a whole down into a lower level of the name space.


A slightly different, but similar, approach might divide the name space into “specialization families”.


So for items that are part of the core standard, we’d continue to use:




For items that aren’t part of the core, we’d use something like this:




rather than sub-committee based URIs:




“spec” in the above is nice and short, but we could also use one of “specialization”, “family”, “spec-family” or “specialization-family”.


The specialization family names might be similar to the groupings we’ve been talking about using for the DITA 1.2 specifications: core (topic, map), techpubs (concept, task, reference), books (bookmap, glossary), learning, machine-industry, ... (don’t worry, these names are just examples, real family names would need to be approved by the TC).


Specializations that currently use “core” URI based identifiers would continue to do so, although we could create alias URIs for some of them if we think there is enough benefit to showing a different organization as part of these identifiers.


All of this is just a thought/question on my part.  I don’t object to using the sub-committee based scheme that was originally suggested by Eric.




> -----Original Message-----

> From: Eric Sirois [mailto:esirois@ca.ibm.com]

> Sent: Monday, October 01, 2007 11:19 PM

> To: dita@lists.oasis-open.org

> Subject: [dita] URI scheme for TC subcommittees



> Hello, Fellow TC members;


> During the latter part of DITA 1.1 the TC approved the use of URIs and a

> URI scheme to uniquely identify DITA XML Schema and its components.  As

> the

> TC subcommittees are getting closer to delivering new industry

> specializations they should create URIs for their schemas.  The URIs are

> used to uniquely identify their schemas so as to make easier to validate

> the content to be processed by XML applications.  This is similar to how

> DTDs use unique a PUBLIC identifier to identify DTDs.


> The design pattern for the current base schemas are:


> urn:oasis:names:tc:dita:xsd:<filename.xsd>:<version>


> I propose that the TC subcommittees use the following design pattern to

> uniquely identify their schemas and its components.


> urn:oasis:names:tc:dita:sc:<subcommittee-

> name>:xsd:<filename.xsd>:<version>



> Here are some samples of how URI would be used in the schema documents and

> XML instance documents.  For instance,

> urn:oasis:names:tc:dita:sc:learning:xsd:learningOverview.xsd:1.0


> The URIs would replace the any instance where are relative or absolute

> path

> URL would have normally been used.


> <?xml version="1.0" encoding="utf-8"?>

> <learningSummary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

>  xsi:noNamespaceSchemaLocation="../schemas/learningSummary.xsd"

>  id="learningsummary">


> would be


> <?xml version="1.0" encoding="utf-8"?>

> <learningSummary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

>  xsi:noNamespaceSchemaLocation=

> "urn:oasis:names:tc:dita:sc:learning:xsd:learningSummary.xsd:1.0"

>  id="learningsummary">


> The same would apply to include/redefine/import in the schemas documents


> <!--  ================ INFO TYPES =====================  -->

>   <xs:include schemaLocation=

> "urn:oasis:names:tc:dita:sc:learning:xsd:learningAssessmentGrp.xsd:1.0"/>


> Kind regards,

> Eric

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

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