Chicken or Egg, XML or XSD

What comes first, XML or XSD? When you start building a project that
will include XML, what would you start on first, building your XML data
file or your XSD schema file?
thanks
Ralph Krausse
www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg
To a large extent, it probably depends on what you're going to do with the
data. Generally though. I'd be inclined to go with XSD first, since that
defines the data model - in the same way that you design a database schema
before doing any INSERT statements. Having said that, I usually go through a
kind of iterative process (for both database design and XML modelling) where
I start with an XML structure (or entity model) on paper that I know is
"kinda" what I need, and then start working out the XSD / table defs needed
for that structure. I then need to think about the various constraints,
relationships, hierarchies etc. and refine the schema from there.
So, to sum up - the answer to your question is both :-)
Of course, somethimes your just given a schema that you have to work with
(e.g. when integrating with external partners or existing systems), so the
choice goes out the window anyway!
Someone else might have a more "formal design methodology" type answer - any
takers!
Cheers,
Graeme
--
Graeme Malcolm
Principal Technologist
Content Master Ltd.
www.contentmaster.com
"msnews.microsoft.com" <no@.no.com> wrote in message
news:%23Hw5kwOkEHA.2680@.TK2MSFTNGP15.phx.gbl...
What comes first, XML or XSD? When you start building a project that
will include XML, what would you start on first, building your XML data
file or your XSD schema file?
thanks
Ralph Krausse
www.consiliumsoft.com
Use the START button? Then you need CSFastRunII...
A new kind of application launcher integrated in the taskbar!
ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg
|||It really depends on the application scenario.
Often, when dealing with interop scenarios, a schema is given apriori. Thus
you start with the schema.
However, one of the strengths of XML is that you can apply XSD late for
validation and apply more than one XSD for a given XML instance (to check
for different constraints). So sometimes, you may start with XML in one
place and with XSD in another, have more than one XSD developed first etc.
Sometimes if devloping markup, you may start with a small instance and
define the schema and instance iteratively.
Sometimes, you do not need (or cannot preview) a schema at all since your
XML may be very dynamic. Sometimes the data already exists and you want to
infer a schema.
I don't think that there should be a one-fit-all solution, but for many data
and document interop scenarios and database design scenarios, starting with
the schema(ta) is often a better way to understand the data.
Best regards
Michael
"Graeme Malcolm" <graemem_cm@.hotmail.com> wrote in message
news:uFrcmQPkEHA.3724@.TK2MSFTNGP11.phx.gbl...
> To a large extent, it probably depends on what you're going to do with the
> data. Generally though. I'd be inclined to go with XSD first, since that
> defines the data model - in the same way that you design a database schema
> before doing any INSERT statements. Having said that, I usually go through
> a
> kind of iterative process (for both database design and XML modelling)
> where
> I start with an XML structure (or entity model) on paper that I know is
> "kinda" what I need, and then start working out the XSD / table defs
> needed
> for that structure. I then need to think about the various constraints,
> relationships, hierarchies etc. and refine the schema from there.
> So, to sum up - the answer to your question is both :-)
> Of course, somethimes your just given a schema that you have to work with
> (e.g. when integrating with external partners or existing systems), so the
> choice goes out the window anyway!
> Someone else might have a more "formal design methodology" type answer -
> any
> takers!
> Cheers,
> Graeme
> --
> --
> Graeme Malcolm
> Principal Technologist
> Content Master Ltd.
> www.contentmaster.com
>
> "msnews.microsoft.com" <no@.no.com> wrote in message
> news:%23Hw5kwOkEHA.2680@.TK2MSFTNGP15.phx.gbl...
> What comes first, XML or XSD? When you start building a project that
> will include XML, what would you start on first, building your XML data
> file or your XSD schema file?
> thanks
> Ralph Krausse
> www.consiliumsoft.com
> Use the START button? Then you need CSFastRunII...
> A new kind of application launcher integrated in the taskbar!
> ScreenShot - http://www.consiliumsoft.com/ScreenShot.jpg
>
>
|||Hello Ralph,
Do you have any more concerns on the reply? If there is any question,
please feel free to post here and we will follow up.
Thanks very much.
Best regards,
Yanhong Huang
Microsoft Community Support
Get Secure! C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn
This posting is provided "AS IS" with no warranties, and confers no rights.

checksum

It is odd. I am trying to use checksum to build an index. The documentation
states that checksum is intended for the building of hash indexes.
However...
I have a table of approx 1.3 million rows and 25 columns (mixed types). I
ran the following statements:
select count(*) as vol, checksum(*) as Hash from <tablename> group by
checksum(*) order by vol desc
This returned 227 records that had the same check sums as another row in the
same table. No row was matched more than twice. This means that 0.01% of the
rows have the same check sums. I then took a look at the rows and they are
very different. They do have the same data types across the columns but there
is a 0.01% chance that my table returns the same checksum despite the data
within them being very different.
This means that I can't really use it as an index. Could there be another
way of creating an index from columns? perhaps an MD5 Hash?
thanks for any help on this.
"David Portas" wrote:

> Elmer Miller wrote:
> That's right. CHECKSUM doesn't necessarily return distinct results for
> different inputs.
> SELECT CHECKSUM(N'ABC') AS ABC,CHECKSUM(N'ASH') AS ASH;
> ABC ASH
> -- --
> 1132495864 1132495864
> (1 row(s) affected)
>
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>
Some other checksums will give you better results but basically no checksum
will guarantee you won't have collisions. Checksums are useful as indexes
just as hash functions are useful in building hash tables even though
uniqueness is not guaranteed. If I understood your statistics correctly,
you would return a maximum of two rows which is pretty good for 1.3 million
candidates. Presumably once you have narrowed the search to two or three
rows you can use some other means to get the exact row you want.
A checksum ensures that no two identical rows will return different
checksums but it doesn't ensure that the same checksum can't be returned
from different rows.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Sharat Koya" <SharatKoya@.discussions.microsoft.com> wrote in message
news:4E79996B-27A5-46B5-8E9B-E3FFC68024D5@.microsoft.com...[vbcol=seagreen]
> It is odd. I am trying to use checksum to build an index. The
> documentation
> states that checksum is intended for the building of hash indexes.
> However...
> I have a table of approx 1.3 million rows and 25 columns (mixed types). I
> ran the following statements:
> select count(*) as vol, checksum(*) as Hash from <tablename> group by
> checksum(*) order by vol desc
> This returned 227 records that had the same check sums as another row in
> the
> same table. No row was matched more than twice. This means that 0.01% of
> the
> rows have the same check sums. I then took a look at the rows and they are
> very different. They do have the same data types across the columns but
> there
> is a 0.01% chance that my table returns the same checksum despite the data
> within them being very different.
> This means that I can't really use it as an index. Could there be another
> way of creating an index from columns? perhaps an MD5 Hash?
> thanks for any help on this.
>
>
> "David Portas" wrote: