[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Designing an XML Vocabulary: The First Two Questions
- From: "James Fuller" <james.fuller.2007@gmail.com>
- To: "Costello, Roger L." <costello@mitre.org>
- Date: Tue, 15 Apr 2008 19:02:06 +0200
On Tue, Apr 15, 2008 at 6:53 PM, James Fuller
<james.fuller.2007@gmail.com> wrote:
> > SUMMARY
> >
> > (a) Creating a new XML vocabulary is a last resort. Use an existing
> > one if possible.
not sure its helpful to make this kind of 'best practice' statement
... being able to generate some immediate data format without having
to worry about some future integration is a big plus.
I am unsure how close we are to having a mythical 'catalog' (cue
people sending links) of all the possible XML vocabularies
representing various problem domains....
but as long as we keep on making new people I am sure we will be
making new vocabularies from which to share ideas.
I know I will live to regret saying this ... but I am fine with having
100+ XML formats for lets say representing addressbook data ... as
long as we can effortlessly transform between them its not such a big
problem (though certain scenarios are like ... sync for example).
> > (b) If you do decide to create a new XML vocabulary, then be sure to
> > first answer these two questions:
> >
> > 1. Is the purpose of the XML vocabulary to encode behavior or to encode
> > data?
> >
> > 2. Is the purpose of the XML vocabulary to markup one specific kind of
> > data, or to markup multiple diverse kinds of data?
>
irregardless of what you intend; XML once encoded is firstly data ...
past that, most XML to be useful has some sort of processor (passive
or active), which probably generates some richer inference (not
necessarily in an RDF sense) or 'does some work'.
I find myself more struggling with questions such as how to package
compound XML documents ... e.g. I know I can reuse some other XML
vocabularies for solving part of the problem (cue all those
microformats or other XML vocabs like dublin core) but adding more
namespaces tends to complicate matters and comprehension.
cheers, Jim Fuller
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]