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:
urn:oasis:names:tc:dita:xsd:<filename.xsd>:<version>
For items that aren’t part of the core, we’d use something
like this:
urn:oasis:names:tc:dita:spec:<specialization-family-name>:xsd:<filename.xsd>:<version>
rather than sub-committee based URIs:
urn:oasis:names:tc:dita:sc:<subcommittee-name>:xsd:<filename.xsd>:<version>
“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.
-Jeff
> -----Original Message-----
> From: Eric Sirois [mailto:]
> Sent: Monday, October 01, 2007 11:19 PM
> To:
> 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:
> 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.
