[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] URIs and versions
Hi Bruce,
Would the use of the value xmlns instead of namespace, like
http://dita.oasis-open.org/xmlns/, also satisfy your requirements?
Kind regards,
Eric
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - DBA XML Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue Pages (Internal)
"Esrig, Bruce
(Bruce)"
<esrig@lucent.com To
> "'Erik Hennum'"
<ehennum@us.ibm.com>, Paul Grosso
01/05/2005 03:13 <pgrosso@arbortext.com>
AM cc
DITA TC list
<dita@lists.oasis-open.org>
Subject
RE: [dita] URIs and versions
Is it worthwhile to distinguish the namespace URIs by adding "namespace" at
the front of the namespace URIs?
http://dita.oasis-open.org/namespace/
majorVersionIdentifier/nameCategory/namedThing
If namespace URIs and schema URIs enter the same conversation, this would
help to keep them apart.
Bruce Esrig
-----Original Message-----
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, January 04, 2005 11:39 PM
To: Paul Grosso
Cc: DITA TC list
Subject: Re: [dita] URIs and versions
Hi, Paul:
Good points. In addition to the identifying namespaces for the
document types,
we need the URI locations where the schema files can be referenced.
What's the advantage of using "xml" instead of the more explicit
"dtd"
for the URI locations? I'd incline toward:
http://dita.oasis-open.org/schema/releaseIdentifier/schemaType/
file
as in:
http://dita.oasis-open.org/schema/1.0/dtd/concept.dtd
- The DTD definition of the concept document type in the null
namespace
for the 1.0 release.
http://dita.oasis-open.org/schema/1.0/dtd/concept_ns.dtd
- The DTD definition of the concept document type in the namespace of
the concept document type for the 1.0 release.
http://dita.oasis-open.org/schema/latest/dtd/concept.dtd
- The DTD definition of the concept document type in the null
namespace
in its most recent version (not necessarily the most recent release).
...
http://dita.oasis-open.org/schema/1.0/xsd/concept.xsd
- The Schema definition of the concept document type in the null
namespace for the 1.0 release.
http://dita.oasis-open.org/schema/1.0/xsd/concept_ns.xsd
- The Schema definition of the concept document type in the namespace
of the concept document type for the 1.0 release.
http://dita.oasis-open.org/schema/latest/dtd/concept.xsd
- The Schema definition of the concept document type in the null
namespace
in its most recent version (not necessarily the most recent release).
...
On namespaces and versioning, it's true that changing the namespace
creates
an upgrade task. Conversely, isn't it possible that keeping the same
namespace
could cause processes to blow up if they work with the old version of
a document
type but not the new version?
I would note that, because DITA provides a modular type hierarchy,
the
DITAArchVersion attribute indicates the version number only of the
architecture.
Document types could upgrade independently of each other. Conversely,
the
DITA architecture itself could in principle change without changes to
the
document types.
Some useful references:
http://www.w3.org/TR/webarch/#ext-version
- The Web Architecture requires a policy on versioning and namespaces
but
doesn't dictate that policy.
http://www-106.ibm.com/developerworks/xml/library/x-tipnamsp.html
http://lists.xml.org/archives/xml-dev/200103/threads.html#00995
- A summary and thread discussion of versioning and namespaces. The
compromise solution of a "latest" version would, I think, only work
when the
namespace resolves to the definition file, which is useful for schema
files
but not for an abstract document type that's implemented in multiple
schema languages. So, removing that option, the best practice
seems to be to change the version identifier only for major upgrades.
It's interesting that, in the draft Relax NG grammars for XHTML 2,
the
namespace remains the same as XHTML 1. That consistency might be
temporary -- I didn't find any statement on the subject:
To sum up, I'd suggest a convention like:
http://dita.oasis-open.org/majorVersionIdentifier/nameCategory/
namedThing
where majorVersionIdentifier is the year and nameCategory can
currently be
"architecture" for properties of the DITA architecture
"doctype" for the document types that populate the architecture
and, in the future, possibly "module" (or "topic" and "domain") for
type modules
that populate the architecture.
For example:
http://dita.oasis-open.org/2005/architecture/DITAArchVersion
http://dita.oasis-open.org/2005/doctype/concept
http://dita.oasis-open.org/2005/module/highlighting (possible
future)
The specification would note that the OASIS TC will change the
version identifier
only on major changes (or even "incompatible changes"?) to the
identified DITA
component.
Does that work?
Erik Hennum
ehennum@us.ibm.com
"Paul Grosso" <pgrosso@arbortext.com> wrote on 01/04/2005 02:46:06
PM:
> I didn't catch the exact details of our plans for
> URIs during the telcon, but I do remember discussing
> getting the version info in there.
>
> I remember related discussions in the W3C and elsewhere,
> so I did some checking and talking to others.
>
> For organizing the various DTD and/or XML Schema modules
> and shells and such, having the version as a step in the
> path usually works well. It occurs to me that we might
> want to have both XML Schemas and DTDs for DITA at some
> point. DocBook, which is in a similar situation (and in
> fact also has SGML DTDs and RelaxNG grammars) uses a
> scheme can be seen at http://docbook.org/xml/
> Our analogy might be something like:
> http://dita.oasis-open.org/xml/1.0/the-various-modules-etc
> The "xml" step--which implies XML DTDs--allows us later to
> have an "xsd" subtree containing schemas and so forth.
>
> All the above is about URIs for organizing the files,
> aka system identifiers.
>
> As far as namespace names, there are problems with putting
> the version into the namespace name. I'm not sure if that
> was what was being discussed today or not, but if it was,
> we might want to continue the discussion.
>
> If you put the version into the namespace name, then you
> are putting all your elements into a completely different
> vocabulary every version which makes it very difficult to
> transition from one version to the next. This practically
> guarantees serious legacy conversion problems whenever one
> wants to transition to a new version. None of your XSLT
> stylesheets that work with the old namespace will work on
> any elements in the new namespace.
>
> Unless we really want to enforce that "a topic in DITA 1.0"
> is a completely different and incompatible object compared
> to "a topic in DITA 1.1", then I don't think we want to have
> the version info in the namespace name. Instead, applications
> that need to know the version of a given bit of content should
> inspect the DTDArchVersion attribute and/or some similar version
> attribute we may wish to add to all root elements. But we should
> have a version-less namespace for DITA.
>
> This is somewhat analagous to the fact that all XHTML--whether
> strict or loose and regardless of version--uses the same
> http://www.w3.org/1999/xhtml namespace name [1] so that a <p>
> element is always a <p> element regardless of the details of
> the version of the document it's in. (The "1999" is NOT any
> kind of version indicator--it is merely the way the W3C doles
> out namespace names.)
>
> paul
>
> [1] http://www.w3.org/TR/xhtml1/#normative
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]