[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A few lessons I have learned (June, '03)

• To: xml-dev@l...
• Subject: Re: A few lessons I have learned (June, '03)
• From: Norman Walsh <ndw@n...>
• Date: Fri, 06 Jun 2003 16:45:44 -0400
• In-reply-to: <3EE0E811.9136A671@m...> (Roger L. Costello's message of"Fri, 06 Jun 2003 15:14:25 -0400")
• References: <3EE0E811.9136A671@m...>
• User-agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.1 (gnu/linux)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ "Roger L. Costello" <costello@m...> was heard to say:
|    - separate hyperlink definitions from data (put hyperlink 
|      definitions in a linkbase)

Do you have suggestions for some good, off the shelf tools, that make
managing external linkbases practical for ordinary users?

| 2. Freedom is not "do anything you want".  That is chaos.  Unbridled XML
| leads to chaos.  Freedom is brought about through discipline.  Bring
| order to instance data by conforming to a design pattern.  

In other words, validate your data?

|     The RDF Class/Property/Value design pattern seems like a 
|     good choice to control the chaos.

For some class of applications, perhaps, but there's no silver bullet
in there.

| 3. Minimize exacting requirements on the *form* of instance documents. 
| Expect diversity of expression. 
|
|     Corollary: In designing schemas apply liberal quantities 
|                of <any> and <all>; minimize use of <sequence>
|                and minOccurs="1".

Alternatively, establish precise and exact controls over the form of
instance documents.

What value is there in validity if it doesn't give you any insight
into the form of the data.

Granted, if your application domain is one in which RDF triples are
the answer, then perhaps control over the form is less important.
You're going to slurp them all out of XML and build a graph anyway,
right?

But if the XML expression of your data *is* the model (and not just
some funky serialization of some other model) of your data, you better
make sure you understand the instances you get.

| 4. Take a step forward to machine understanding of instance data by
| documenting how the data relates to other things in the world: How does
| the class of data in the instance document relate to other classes of
| data? What are the characteristics of the properties?  Answers to these
| questions constitute a logical model.  

Sure, if your data has an obvious analog to the real world.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@S...    | O for a Muse of fire, that would ascend / The
XML Standards Architect | brightest heaven of invention, / A kingdom
Web Tech. and Standards | for a stage, princes to act / And monarchs to
Sun Microsystems, Inc.  | behold the swelling scene!--William
                        | Shakespeare, Henry V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+4P14OyltUcwYWjsRAk+0AJ968pzgcr6S2KsK/F500PeormMUbACgsbUR
GlPUNjU5AJtRjeVEWMAGwm8=
=4VJ8
-----END PGP SIGNATURE-----

• References:
  • A few lessons I have learned (June, '03)
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: RE: Doc vs. Data
• Next by Date: Re: YAML Ain't Markup Language
• Previous by thread: Re: A few lessons I have learned (June, '03)
• Next by thread: Re: A few lessons I have learned (June, '03)
• Index(es):
  • Date
  • Thread