omd-development Mailing List for Open Magic Data (OMD)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> I'm not exactly sure what you mean by "sets".  Based on looking around
> the OMD project webpage, it seems like OMD is also about developing
> applications for building deck files and what not.  Did one of the
> applications contain a card database for deck building?

There are a couple issues here...

a) There is the problem that the content of the files is copyrighted
intellectual property of Wizards.  As such, we cannot distribute the card
texts ourselves without permission or serious editing as was previously done
by Hogan at NGO and will not put it on SF.net because it will, inevitably,
be taken down.  Dragonstar Studios ended up working with wizards for this
reason.

b) A standard will not be accepted if there is no application that
demonstrates feasibility and also makes good use of it. Java and XML making
great partners, I built apps on them (including a deck editor that had the
features that I always wanted).

> I guess my impression for what to do with the XML standard once
> developed was slightly different.  While I think the sorts of
> applications that are being written are useful, I think that the real
> kicker (pun kinda intended) here is the promise of interoperability
> between programs.  That means that I should be able to download a deck
> file from brainburst.com, play with it in apprentice or magic
> workstation, tweak it in the java editor that you folks provide, print
> it out using a decklist printing tool to take to my tournament, and then
> post it on my own website by using XSLT along with my description of how
> the tournament went.

I don't think it's really all that different.  Any standard is not a
standard without
users.  =)  For this reason I also provided an export to apprentice format
feature,
hoping that this would lead over to the XML standard.

> I feel like the key to making this interoperability happen is having a
> standard that is independent from any single application (though
> certainly getting feedback from all the potential users of the
> standard).

I do think maybe you've gotten a bit of a misunderstanding of the process
here...
Hogan started OMD and started some standards.  I took it and ran, but it was
never
without input.  The apps were my own creation, using the standard and
proving validity.

> My DTD is at:
> http://xenon.stanford.edu/~mdevine/dtd/magic-deck.dtd
>
> In many ways, I feel like my DTD is a superset of the OMD superset.  My
> DTD includes all of the elements that the OMD DTD includes, with the
> exception of the card "Comment" element.  In some of my elements have
> different names, for example, I use the name "edition" instead of Set.
> I prefer the name Set to edition.

I included the comment because I saw many sites at the time including
comments about specific cards in the deck.  I like the addition of the event
section, though I would like to see it included in its own section (i.e.
eventList) even though you can of course do a 0-many inclusion.  It just
helps clear things up, particularly in viewers like IE where you can
collapse whole sections of tree to ignore them.

> I personally like the element name "deck" instead of "OMDDeck". I
> realize that you may have named it OMDDeck so as not to interfere with
> other XML markup for things like Yu-Gi-Oh decks.  There is a way to do
> this, and still use the name "deck".  If you look in my stompy.xml file,
> you will see that I use the xmlns element in deck to define an XML
> Namespace.  That means that "deck" and everything included within it, is
> really considered as "http://xenon.stanford.edu/~mdevine/mtg:deck" which
> is never going to conflict with anything.  If you look in my XSLT file,
> I define a shorthand for that URL at the very beginning so I can match
> against "mtgml:deck".

Heh.  Keep something in mind here before passing judgement:
a) Yu-Gi-Oh did not exist (though Pokemon did)
b) Schemas were still very new
c) Namespaces were still very new
d) None of us building the standards at the time knew much yet about XML.

The fact is, all of the above tend to indicate it was an idea somewhat in
advance of its time.
I picked OMDDeck at the time to make people start to look for what OMD was,
and as you hint, to avoid some of the collisions.  You are quite correct,
though, that namespaces and clearer schema could certainly solve these
issues.

> There are other elements and attributes that I have in my dtd that I
> think could be useful (though the OMD apps certainly wouldn't need to
> use them).  The most bizarre ones are the "groups" and "group"
> elements.

I'm not sold on the groups elements; I'd have to see some practical
examples.
(After all, we already have main deck and sideboard groupings.)  This is one
of the good things about XML though.  There can be extra info included that
if the app doesn't want to use, it doesn't have to. =)

> I've added a date attribute to format
> because of the formats that change with time.  "Extended" isn't
> sufficient to know the allowed card pool, but "Extended" on 1/16/03 is.

I'll pause here to note that we never did manage to agree on a way of
standardizing the description of a format.  Fields change so frequently it
would be difficult to keep up to date, besides the ability to pick/locate
them.  So this might be a good place for you to ponder deeply should you
feel motivated. =)

> Basically what I'm interested in is trying to make the XML that we're
> working with a standard for the online Magic community.

That was the dream, yes. =)

> I think in
> order to do this, we need to:
>
> 1.) broaden the dtd to include some of the features that other
> applications might want (I have an attempt at
> http://xenon.stanford.edu/~mdevine/dtd/magic-deck-omd.dtd)

As noted, I like the event inclusion.

> 2.) create an xml namespace URI for the standards.  Nothing actually
> needs to be at that url, it's just a string that uniquely identifies the
> OMD namespace.  I suggest "http://sourceforge.net/projects/omd"

Au contraire, the url provides a starting point for information about it.

> 3.) write documentation about the standard and make it available on the
> OMD page

Great idea... if someone wants to write some docs on this.  ...
>
> 4.) communicate with web site maintainers and application developers to
> convince them of the benefits of using this standard

Also a good idea, but there need to be some documented benefits and examples
before you can sell them on it.  If Hogan is still lurking around here
somewhere, he might be a good resource to start with.

> I'm willing to work on all of the above.  I just need to know if this
> plan makes sense and fits in with the OMD project.  Sorry if this was a
> lot of information to dump on you guys all at once.  Let me know what
> you think.

I'm open to any fresh efforts, though I'd like to see the work that's
already been done kept as the core.  (Standards aren't much if they show a
history of getting tossed out, after all!)  And while it's good to have an
optimist with a pie-in-the-sky dream amongst us, try not to get *too*
optimistic.  Web sites tend to not share their best material so as to keep
their audience, and there just aren't that many apps out there.  Those that
are out there won't likely change rapidly; Apprentice has been at 1.46
for... 5 years?  Something like that, anyway.  Version 2 has been in the
works longer than that.  And as proud as I am of Deck Mentor, it's not been
updated in >2 years.  I hoped there would be some interest, but it's really
been very low-key and it needs data sets in order to work.  If you can drum
up some interest on the e-leauges, that would probably be the best way to
gather interest in the standards.

--Dave / Sage Sam

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (6)	Sep (5)	Oct (22)	Nov (4)	Dec (23)
2001	Jan (14)	Feb (5)	Mar	Apr	May (6)	Jun (1)	Jul	Aug (8)	Sep	Oct (1)	Nov	Dec
2002	Jan	Feb	Mar (1)	Apr	May (7)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan (5)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

omd-development Mailing List for Open Magic Data (OMD)

omd-development — Discussion of issues pertaining to development of OMD standards and apps