[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] URI scheme for TC subcommittees
Hi Jeff,
I agree with your suggestion that we should not include "sc" as a
reference to a subcommittee in the URN name but rather something that
a) is more in-line with the work that is going for 1.2
b) a term that is more descriptive of it purpose.
I would prefer "spec, although "spec-family" is a short, yet still
descriptive token in the URN namespace.
urn:oasis:names:tc:dita:spec-familiy:<specialization-family-name>:xsd:<filename.xsd>:<version>
urn:oasis:names:tc:dita:spec:<specialization-family-name>:xsd:<filename.xsd>:<version>
Either one is fine with me.
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.
"Ogden, Jeff"
<jogden@ptc.com>
To
10/23/2007 12:33 <dita@lists.oasis-open.org>
PM cc
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:
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: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]