RelaxNG is very good, XSD on the other hand is ubiqutos, evry knows
them and it's easy to deal with versioning( the time will come when
DTD will not be able to deal with versioning efficeintly as XSD). As
Subversion client and it's output will change from version to version,
XSD seemed to be a better bet that DTD.
This is certainly not XML schema bashing session, I'll have to look at
them in a way that's XSD allows subversion to integrates well with
major platform. We do .Net , where XSD is the 1st class citizen thus
it allow us to intergrate with NAnt and numerous tools and cutome
codes lot easier easier. We could build web services around them
withouth too much hacking if it were in XSD. we could turn svn
commands to web services operation with little effort. What a nice way
for an application to evolve.
I'll review the initial xsd on the repos will make some suggestion to
improve the readbilty and interoperabilty with XSD tools.
On 9/28/05, Julian Reschke <julian.reschke@gmx.de> wrote:
> Lieven Govaerts wrote:
> > No, I'm talking about:
> > 1. Efficiency of storage: why would I want to store a string in say an RDBMS
> > when I could store an integer?
>
> What does this have to do with the presence of a DTD/Schema/whatever. At
> some point you need to *know* that it is an integer; and it doesn't seem
> to be relevant for that through which way you find that out...
>
> > 2. Validation: if the recipient is dependent on a certain field containing only
> > integers, then that should be defined in the contract that recipient has with
> > the supplier, ie the schema definition.
>
> The contract doesn't need to be a schema file. I do agree that it's good
> to have a contract; it just doesn't mean it needs to be a schema file in
> general or XSD in particular. For instance, many IETF protocol just
> constrain the values in prose or in ABNFs, and that works as well.
>
> > ...
>
> Best regards, Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 28 15:39:28 2005