Menu
▾
▴
Re: [Omd-dev] tuning of Card schema
|
From: Hogan L. <Ho...@Ne...> - 2001-08-24 16:54:04
|
Anything I don't comment on was fine... 1) caps vers non caps... (And changes because of some xml files you found) The official OMD set lists are on neutralground.net - you should go by how those are and not other xml files. The whole point of a standard is that it is a standard. If you see conflicts with the official expansion files on NGO and the schema then please point that out... but the point of a schema is to prevent just the problem of having someone use caps and someone else not - this would case xml parsers to not work on some of the files. Because we need a standard and since I started this whole thing I'm going by what I did as the standard.... if you see conficts in my expansion files I will fix them. If you don't think I made the right choices - great! all you have to do is convince me that another choice is better and I will change it. But to make a change to the schema based on something that can be fixed with a search+replace in an editor for some existing files does not make sense to me - does it make sense to you? 3) Multi inheritance - yes schema does support it - this is why I waited for schema to come around as op to using DTD - they suck with no way to do inheritance. At 08:20 AM 8/24/01, you wrote: >(to keep this relatively short, i cut out some stuff, noted by "...") > > > ... > > When something is a creature then the card needs to have > > an additional field "sub-type" that states what "type of creature it > > is" > >isn't this covered by CreatureCard? > ><xsd:complexType name="CreatureCard"/> > <xsd:complexContent> > > <extension base="Card"> > <xsd:element name="subtype" type="xsd:string"/> > <xsd:element name="power" type="positiveInteger"/> > <xsd:element name="toughness" type="positiveInteger"/> > </extension> > </xsd:complexContent> ></xsd:complexType> > > > > When something is an enchantment then the card needs to have > > an additional field "sub-type" that states what it enchants. > >ok. i'll add that. i'll also remove "Enchant Land", >"Enchant Creature", from CardTypes, since the new >extension covers that. > ><xsd:simpleType name="CardType" base="xsd:string"> > <xsd:enumeration value="Artifact"/> > <xsd:enumeration value="Creature"/> > <xsd:enumeration value="Artifact Creature"/> > <xsd:enumeration value="Instant"/> > <xsd:enumeration value="Sorcery"/> > <xsd:enumeration value="Land"/> > <xsd:enumeration value="Enchantment"/> > </xsd:simpleType> > > > <xsd:complexType name="EnchantmentCard"/> > <xsd:complexContent> > <extension base="Card"> > <xsd element name="subtype" type="EnchantmentTargetType"/> > </extension> > </xsd:complexContent> > </xsd:complexType> > > <xsd:simpleType name="EnchantmentTargetType" base="xsd:string"> > <xsd:enumeration value="Artifact"/> > <xsd:enumeration value="Creature"/> > <xsd:enumeration value="Land"/> > <xsd:enumeration value="Permanent"/> > </xsd:simpleType> > > > > When something is an artifact it can also be a creature (with > > creature > > attributes) - how do we do this... any ideas? > >i'll have to think about that. since there's currently no >Artifact "subclass", we can get away with another CardType. > > > ... > > ># - minor changes, to line schema up with current xml set files > > ># - added single-letter rarity codes > > > > how would this work? seems a program would have to check for both > > - makes more work for the end programmer... any ideas? > >this was mostly pragmatic: all of my <set>.xml files (mostly dated >Jan 2001) use the single-letter code. > >i agree that aliasing tends to cause headaches, but if you want >to stick with "Uncommon", we'll have to update all of the existing >xml. > > > ># - replaced "Colorless" with "None" > > > > why is none better? > >it's not - just lining up with the existing xml: all "colorless" >examples i could find in the xml used None. > > > ># - upper-cased colors and types > > ># - is xml case-sensitive? > > > > XML IS CASE SENSITIVE - please be careful! > > my plan was to just have "high" level defines be uppercase > > (eg Card, Expansion, Deck etc.) > >again, just lining up with the current xml, which uses "White", >"Blue", ... > > > ># > > ># Notes: > > ># - i would like to add a <state> element, for arbitrary stuff, > > ># so that i can store the full state of a game/table > > ># > > ># <state key="tapped" value="true"/> > > ># <state key="location" value="500@300"/> > > ># <state key="z-order" value="5"/> > > ># > > ># any objections? (note: this might be a way to "try" things > > ># before schema-izing them, too) > > > > The way to do this is to create a NEW top level data item... > > called > > <StateCard> > > This would include all the stuff from the card schema (see schema > > doc on how to do this) and the new stuff you need for state > > information. > > > > If you want to start creating a schema for functional information > > (eg when this comes into play destroy target non-black creature) > > please call this schema <FunctionalCard> > > (Note for any type of simulator to work you need to have the concept > > of a FunctionalCard being an effect that goes on the stack. If this > > is not clear email me.) > > > > If you want to create a schema for collection information > > call this schema <CollectionCard> (eg condition, value, location > > purchased etc) > > > > Can you think of any other card schemas needed besides > > Card > > StateCard > > FunctionalCard > > CollectionCard > >i see where you're going with this, but i wonder if schemas support >multiple inheritance >("mixins" is really what i want): i want all of these >things to "be" Cards, but i can see scenarios where >i will need a single Card, with state, functionality, >collection info, and possibly other stuff > >i'll think about this some more > > > >__________________________________________________ >Do You Yahoo!? >Make international calls for as low as $.04/minute with Yahoo! Messenger >http://phonecard.yahoo.com/ > >_______________________________________________ >Omd-development mailing list >Omd...@li... >http://lists.sourceforge.net/lists/listinfo/omd-development |
