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] URIs and versions

One could use "dtd" in place of "xml".  DocBook uses "xml" because it
also has DTDs for "sgml".
Note that I (and DocBook) recommended that the version come after
the schema technology.  That is, .../dtd/1.0/... instead of the other way
around.  This is because you may well issue a new DTD version (perhaps
to correct a bug) when you don't issue a new XSD version.
So that implies:
but then I don't see the point of the "schema" path step.
Again, note that all this is about the system identifiers, not the namespaces.
Your suggestion for namespace names seems okay to me, though I might
not use the year for the major version step (though I could live with that).
For DITA 1.0, we're just defining a single namespace, right?
As far as DITAArchVersion, I'm a little fuzzy on the details. Perhaps we
also need a DITADoctypeVersion attribute--I'm not sure. All I'm sure of is
that we don't want DITA namespace names to change every time we issue
a new version of the schemas.

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, 04 January, 2005 22:39
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:

as in:

- The DTD definition of the concept document type in the null namespace
for the 1.0 release.

- The DTD definition of the concept document type in the namespace of
the concept document type for the 1.0 release.

- The DTD definition of the concept document type in the null namespace
in its most recent version (not necessarily the most recent release).


- The Schema definition of the concept document type in the null
namespace for the 1.0 release.

- The Schema definition of the concept document type in the namespace
of the concept document type for the 1.0 release.

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

- The Web Architecture requires a policy on versioning and namespaces but
doesn't dictate that policy.

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

where majorVersionIdentifier is the year and nameCategory can currently be

and, in the future, possibly "module" (or "topic" and "domain") for type modules
that populate the architecture.

For example:

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

Does that work?

Erik Hennum

"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]