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