Hello Lech,

Another approach would be to use version control of one sort or
another ... eXist has a versioning extension and MarkLogic has
something akin to this in a library module (if u have access to
MarkLogic), otherwise any source control will give you what you want.

As with any data structure, if the underlying schema itself is
volatile then you can experience pain in the form of backwards
incompatibility ... so if you do go down the route of embedding
version metadata you may want to test what happens when you change
your schema and how to mitigate the impact of such things on your
version metadata.

good luck, Jim Fuller

On Thu, Oct 1, 2009 at 4:44 PM, Lech Rzedzicki <xchaotic@g...> wrote:
> Hi all.
>
> I am at a fortunate stage where we are redesigning our XML schema so
> that it fits our requirements better.
> To give you an idea of the XML we're dealing with, it's loosely based
> on DocBook and used for multi-channel publishing.
> Some frequent scenarios include updating XML with new content,
> comparing versions, different languages, sending diffs to tranlation,
> but also producing slight variations depending on the output. Tracking
> changes (by being able to see what's been added and deleted) is also a
> nice to have feature.
> Basically what I aim to put in place is structures to help with these
> function that are not too verbose to overwhelm editors, yet powerful
> enough for 'future' scenarios.
>
> My initial thoughts are to employ xml:id attributes on block-level
> elements and add a set of attributes for each facet of profiling,
> possibly reusing DocBook attributes such as condition, version,
> audience, but my fear is that it won't powerful enough in the future.
>
> I would love to hear your general thoughts on best practices in this
> area of managing XML content and specifically on:
>
> 1. How low should we go with id's on elements? My main concern here is
> making diffs as easy as possible and possibly identifying chunks of
> xml that are as small as possible, making translation cheaper. On the
> other hand should I be bother at all about the performance, since all
> the documents are size-limited to a book size of ca 1000 pages(a few
> MB of XML)?
> 2. Use a possible verbose set of elements/attributes on the elements
> directly or use a meta-attribute that links to an attribute/element
> set in a secondary file? (less verbose but more complex)
> 3. Are 'add' and 'remove' sufficient change tracking marks to cover
> all scenarios? (I think any more complex edits such as update can be
> built up from those two)?
>
> I really hope I can get some good feedback from you and thanks in
> advance for that,
>
> Lech Rzedzicki
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php