Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: 3rd try on versioning question

From: "Dean Hiller" <dean@---------.--->
To: <noah_mendelsohn@--.---.--->
Date: 10/21/2004 5:31:00 PM
no doubt on "versioning is a very very hard problem."  I have thought about
it many times.  Recently I told our guys who are involved in the w3c stuff
to wait on contacting people and see what comes out of w3c.  I feel much
better knowing people are thinking about the issue.
    I come from a world of j2ee descriptors, xml for api's, xml for SOAP
etc, xml for hibernate mapping, etc.. I will have to read the links you gave
me in my spare time.  I am very interested.
thanks,
dean


----- Original Message ----- 
From: <noah_mendelsohn@u...>
To: "Dean Hiller" <dean@x...>
Cc: <xmlschema-dev@w...>; "David Orchard" <dorchard@b...>
Sent: Thursday, October 21, 2004 11:15 AM
Subject: Re: 3rd try on versioning question


> RESEND (with propoer cc: address for Dave Orchard)
>
> Dean Hiller writes:
>
> > wow, alot of great responses this time.
> > I really like the counter on the html example.
> > That is really good.
>
> I'm glad it was helpful, thank you.
>
> > I will have to think more about that.  It really
> > depends on the way html authoring is done these
> > days.  I guess we are not to the point where it
> > is primarily done with tools yet especially when
> > it comes to jsp's.
>
> Perhaps there is still a bit of confusion.  HTML is only an example.  Many
> users of XML have vocabularies that would look unnatural or inconvenient
> if they sprouted explicit version control on individual instance elements
> after the initial release.  Whatever we do needs to anticipate the needs
> of such users, not just those who author HTML.
>
> You might be interested in an analysis that I did for the schema WG and
> later posted in a publicly accessible archive [1].  This analysis is not
> consensus of the Schema WG;  there are other members of the WG who have
> somewhat different view of these issues and who especially would differ
> with some of the mechanisms discussed in the second part of the note.  You
> may also want to keep an eye on the work that David Orchard and Norm Walsh
> have been doing toward a TAG finding [2] on XML Versioning (draft at
> [3]--I wouldn't be surprised to see new drafts soon).
>
> At the very least, I hope that you will get a feeling that we are all
> trying hard to understand the requirements and use cases, and that taken
> together those use cases embody a broader range of concerns and
> constraints than many casual observers might notice.  Whether we can in
> fact do something useful in this space, either by providing explicit
> mechanisms or best-practices advice remains to be seen.  Versioning is
> known to be a very, very hard problem.
>
> Noah
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2004Aug/0010.html
> [2] http://www.w3.org/2001/tag/findings
> [3] http://www.w3.org/2001/tag/doc/versioning-20031003
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>


From nobody@w... Sat Oct 23 04:43:40 2004
Received: from wiggum.w3.org ([128.30.52.23])
	by frink.w


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent