Wordman's XML, Discuss XML schema for code projects |
Wordman's XML, Discuss XML schema for code projects |
Sep 1 2005, 08:26 PM
Post
#1
|
|
Neophyte Runner Group: Members Posts: 2,077 Joined: 14-September 04 Member No.: 6,658 |
I found this poking around and thought it interesting. I'm a total coding n00b, but I have a lot of walk-over-to-Frank's-office-and-bug-him type help to tap developing in the Visual Studio/C#/XML/Windows environment. So that's what I'm looking at.
(which I guess means I'm also tossing my hat into the developing SR software ring for the good and ill it will come to :) ) I'd really like to hear some comments/analysis of this schema as a good or bad distillation of SR gear/mechanics/etc (Rather than reasons why approaches X, Y, and Z that aren't XML are better). Thanks. |
|
|
Sep 1 2005, 10:45 PM
Post
#2
|
|
Manus Celer Dei Group: Dumpshocked Posts: 17,006 Joined: 30-December 02 From: Boston Member No.: 3,802 |
I haven't looked into his proposal, but I'm actually writing my own. Working on some for SR4 first, then I'll be going back and focusing on SR3 (more complex, but more personally rewarding).
~J |
|
|
Sep 2 2005, 12:50 PM
Post
#3
|
|
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
I think this proposal wrongly separates "definition" vs "usage". It only allows using a pre-defined set of elements, or to always redefine the same things. This is a problem with generator tools.
Say I have defintions for "Car" and "Car Enhancement". I can "use" these for someone who owns a "Car"+"Car Enhancement". That is ok. But what if I want to flood the market with such a car named "Enhanced Car"? Solution 1: for each one, I use "Car"+"Car Enhancement" Problem 1: copy/paste is tedious task if at all implemented! Solution 2: I create a new definition for "Enhanced Car" and use it Problem 2: I need another program to create the definition The preferred solution would be to label the "Car"+"Car Enhancement" as "Enhanced Car", but a "definition" cannot be created easily from a "usage". Nothing created through combination can be re-used, so car/deck/gun generators are semi-useless or need to require much much more work. What I would propose is something much much simpler, that does not really need XML (not that I say XML must not used for it). First, do not separate between "definition" and "use". A thing: . has intinsic properties (like price, name, weight...) . refers to other things (gun has ammo) . inherits properties from other things (jackrabbit is a car) thing { name=Car } thing { name=Car Enhancement } thing { name=Enhanced Car is_a=Car has_a=Car Enhancement } This way, anyone can reuse the "Enhanced Car". I am (very slowly) working on a more understandable explanation for my proposal. My inspiration comes from class-based vs prototype-based languages. |
|
|
Sep 2 2005, 04:03 PM
Post
#4
|
|||||
Moving Target Group: Members Posts: 639 Joined: 22-April 02 Member No.: 2,638 |
How exactly would that differ from an XML implementation, e.g.:
XML (with the right schema) would work fine for this; there really isn't any need for a new, proprietary definition language, IMHO. |
||||
|
|||||
Sep 2 2005, 04:38 PM
Post
#5
|
|||
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
XML strength are validation and portability. In this case, the amount of checking would be light. Not unusefull, but really far from covering all needed checks. My example did not use XML notation but, as you showed, could easily be transposed. It was not a technical example, only ideas. What I wanted to enlighten is the prototype-oriented approach, where any thing can be used to model a new think, either by direct reference or by simple duplication. |
||
|
|||
Sep 3 2005, 09:32 PM
Post
#6
|
|
Neophyte Runner Group: Members Posts: 2,077 Joined: 14-September 04 Member No.: 6,658 |
My understanding (and I freely admit that it is imperfect - hence the thread) is that definitions record data that is likely to be static (barring errors). And that usage is an instance of data run through a number of rules.
In your example (I won't be showing code snippets sorry)... The tool would have Enhanced Car recorded on the player in question's character sheet as a usage (I like the term instance, but that could just be WoW talking) of the definitions. Really the whole character is a useage of the definitions. I guess I'm not sure what you mean by 'flood the market,' loic.peron. Do you want Enhanced Cars to be available to your other players? Or other users of a given chargen tool? It seems like a tool could populate a list of Available Cars with Enhanced Car if it were designed to do so... Can you explain more fully the break you see between the definition and usage approach? (And thanks, folks, for your answers and discussions so far) |
|
|
Sep 9 2005, 12:15 PM
Post
#7
|
|
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
Okay, lets use definition=class and usage=instance to further the object-oriented-language bindings.
You are right in that following the original proposal a character instance would have an instance of a car enhanced with an instance of car enhancement. Everything produced by a generator is only a bunch of instances. What I want is use the design rules to create a new car/deck/gun/character and have it handy as if it were canon; I mean not all available cars have been listed in any sourcebook, and new models get produced every time. In practical terms it means to be able to hand it over to anyone (including me) to use as he wishes, either players or masters, to use in any program - I do not envision only character generators, but any generator, and eventually any SR-oriented program like a MUD or MMORPG. Here is then the problem: Yes I can create an instance of a car and add an instance of enhancement to it, but No I can not re-use it as it is not a definition. Here is the - in my eyes - fundamental problem with this class/instance separation, as it does not allow any reuse of the product of generators, be it a new car, a new gun or a generic gang punk. Or at the expense of doubling all the work needed for programs to produce instances and definitions. What I envision in a prototype-oriented system, where there are only instances, and thus anything available may be used as a definition, wether it comes as-is from a sourcebook or from a generator. You may search a by for prototype-based vs. class-based object-oriented approaches - I do not have a good link to provide at this time. The basic idea is to be abe to use any instance as a template for a new one, and be able to add or alter any new property to an instance. All existing 'Ares Predators' are copies of the original template, but some of these also carry some enhancements. Any one can be used as a template for a new 'Ares Predator II' template if one wishes, for example one with a Smartlink enhancement. |
|
|
Sep 23 2005, 08:39 PM
Post
#8
|
|
The Dragon Never Sleeps Group: Admin Posts: 6,924 Joined: 1-September 05 Member No.: 7,667 |
I don't think there is any inherent difficulty here.
All you are trying to ensure you can do is the following; Building a Character Select a Gun from Gun Collection Modify Gun - Add Modified Gun to Character - Add Modified Gun to Gun Collection All you need to do is ensure the definition of the Modified Gun meets the requirement for all gun in the Gun Collection. Just make the Gun modifications part of Gun properties collection? |
|
|
Sep 24 2005, 10:48 AM
Post
#9
|
|||
Manus Celer Dei Group: Dumpshocked Posts: 17,006 Joined: 30-December 02 From: Boston Member No.: 3,802 |
A properly-written W3C Scheme should be able to check things relatively tightly. I'm really not clear on your other objection, or rather how it applies to XML. ~J |
||
|
|||
Sep 27 2005, 10:49 PM
Post
#10
|
|||
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
Well, my structural objections are orthogonal to XML use. XML is just a humean-readable portable hierarchical format. I just really think it is the better format for exchange between programs in this case. But there still is the question of a data model. My objection to the definition/usage separation is that I want to be able to use any combination of usage as a definition, thus completely nullifying the intent of this separation. |
||
|
|||
Sep 27 2005, 10:59 PM
Post
#11
|
|||
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
What a limited view you have! There are other uses fot these data out of a simple one-time character generator. What I am trying to ensure isbuild whatever equipment/character/critter may be created using generation rules (there are many through SR) and on a second time re-use said creation. Build vehicle (bike): - select chasis - select engine - select modifications -> save my_bike Build weapon (gun): - select frame - select enhancements -> save my_gun Build character (ganger): - select race - select basic equipement - add my_bike - add my_gun -> save my_ganger Build gang: - select my_ganger - modify slightly -> save chief_ganger - select my_goon - modify slightly -> save lieutnant_ganger without having to redesing multiple time the save bike or gun (in this example) Would be true for vehicles, decks, guns, critters, spells, characters (PCs or NPCs), and much more. |
||
|
|||
Sep 27 2005, 11:40 PM
Post
#12
|
|
Manus Celer Dei Group: Dumpshocked Posts: 17,006 Joined: 30-December 02 From: Boston Member No.: 3,802 |
See, I'm still not understanding the objection. Unless something uses entirely off-the-walll new features (in which case anything designed to enforce canon or anything like it would fail), I don't see why you wouldn't be able to do exactly what you just proposed with an XML data format.
Though… I just reread the thread, and I'll grant that it's entirely possible that Wordman's proposal is flawed in the ways you outline, and that in general you aren't saying otherwise. ~J |
|
|
Sep 29 2005, 09:38 AM
Post
#13
|
|||||
Target Group: Members Posts: 7 Joined: 26-February 02 Member No.: 2,142 |
There is no objection to XML per se. All I describe can be achieved with an XML data format, at least to avoid re-inventing the wheel. But this cannot rely only on XML capabilities to enforce consistency.
My objection is on the proposed model which goes from XML capabilities to design data model, where I would rather see how data is best modeled for its intended uses before mapping that to XML, even if very few XML capabilities are used. |
||||
|
|||||
Oct 8 2005, 08:20 PM
Post
#14
|
|
Target Group: Members Posts: 81 Joined: 18-August 05 From: Germany Member No.: 7,571 |
I see no difficulties with XML per se but several with Wordmans implementation, too.
But ... the discussion wether you can ensure consistency or reuse your gunmodel with several chars is *totally* independent of the choice between xml, unformatted ascii, binary-streams, or whatever .. Your data-model tells you in which *format* data is saved (wether on the disk or in ram), neither how it is saved, nor how you read or use it nor how you ensurce consistency . . . Your data model tells you "XML with the following dtd" or "Object with the following attributes, saved as strings" . . . Consistency is a question of your program-implementation. Some data-models will make it easier (XML is one of those in most cases) others harder (unformatted ascii). Some data-models make wtiting interpreters or converters easy, others hard (binary streams written to disk in raw access) . . . (Reusing is more easy with a nice data model, but it is possible or impossible whatever format you use). (Okay, maybe I *am* a bit itchy in this field ... But I am studying computer science and perhaps my tutors made me do it) On the whole I suppose xml would be a fine 'language' to save your chars, guns, . . . (I am working on a xml implementation atm) |
|
|
Lo-Fi Version | Time is now: 23rd November 2024 - 01:57 AM |
Topps, Inc has sole ownership of the names, logo, artwork, marks, photographs, sounds, audio, video and/or any proprietary material used in connection with the game Shadowrun. Topps, Inc has granted permission to the Dumpshock Forums to use such names, logos, artwork, marks and/or any proprietary materials for promotional and informational purposes on its website but does not endorse, and is not affiliated with the Dumpshock Forums in any official capacity whatsoever.