Players and scores within a golfml document

[minesadorada]

It seems redundant to duplicate information about the course in  the <player> and <player><round> sections.  Apparently it is possible to include one XML file within another http://www.xml.com/pub/a/2002/07/31/xinclude.html

If a 'static' course golfml file could optionally include an external dynamic <player> and <round> golfml file(s), it would make it much easier to manage scorecard applications.

By combining a course XML, a player XML and a round XML flexibly there should be no duplication of data.

Is this possible?

[minesadorada]

I have made a stylesheet that displays the Playing Handicap and Stableford allowances for each hole.  (in the source section)

It needs to know:

1 ) The <player> name and Exact EGA Handicap

2 ) The Course name

3 ) The Tee-set

I fetch the Player details from the <player> section of the golfml file, but which course and tee-set is still hard-coded in the stylesheet.

Should CourseWriter store this information in the <application> section for the stylesheet to pick up?  I want the stylesheet to be totally generic.

I'm not sure of the (.)dot notations used in the example stylesheets - they seem to duplicate data.

[Pierre Mareschal]

Well, the original idea was to keep things together in a single file, both course data and golfer scores.

In the golfer score section, the golf course being played is referred to by a "unique key" that consists of country, postcode, country club name, course name and tee.

In general, to avoid replication, when I needed to reference an object, I created a "Reference" (See IdentifiersAndReferences.)

But you point at the right problem that I haven't really addressed: How do I get the golf course data? Shall I take a copy in my own golfml document, or reference it?

In my ideal world, each golf course/club would maintain its golfml file with its golf course description, and the golfer would simply "reference" it from within its personal golfml (for score) document. I got hooks ready so that if a golf course changes: there is a "validity" date-from/date-to to keep track of golf course changes.

The problem are simple stylesheet processors that do not always follow xincludes. But yes, xinclude is a solution.

My "programmatic" solution was to explicitely reference the external document (See CREF_Tees for example). but you need a software to fetch that file and include or process it independently.

/p

The Golf Markup Language

--
You received this message because you are subscribed to the Google Groups "Golf Markup Language" group.
To view this discussion on the web visit https://groups.google.com/d/msg/golf-markup-language/-/VYDqN4M_g_cJ.
To post to this group, send email to golf-marku...@googlegroups.com.
To unsubscribe from this group, send email to golf-markup-lang...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/golf-markup-language?hl=en.

[Pierre Mareschal]

Ideally, golf course etc. which are rather static should be confined in a rather static golfml document,  while golf scores and stats should be kept in another more dynamic golfml document.

The later golfml document would reference/include (see previous post) the first golfml document.

Application element was created to store application specific parameters, such as license code, preferences, etc. which are not related to golfml course or golfer structures.

/p

The Golf Markup Language

--
You received this message because you are subscribed to the Google Groups "Golf Markup Language" group.

To view this discussion on the web visit https://groups.google.com/d/msg/golf-markup-language/-/4daPUA5RMmgJ.

[minesadorada]

I suppose it all depends on what you are using golfml for.

1 ) Static: A small course(s) definition to display on a Club's web site

2 ) Semi-dynamic: A fairly small set of players (< 200) for a society or tournament

3 ) Fully dynamic: A large match/tournament database

It also depends on which kind of software is using golfml and how it displays results.

Imagine a busy club with a few hundred players and a couple of tournaments a month along with many regular handicap-qualifying games.  To keep all the data for such a club in one golfml file is possible with the current structure, but surely impractical.  Very soon, the golfml file would grow to megabytes.  Whilst this is OK for a relational SQL database, it is difficult to imagine processing a multi-megabyte golfml file via stylesheets on the web to display a simple scorecard.

While I understand the elegance of a single golfml document for all data, in practical daily use the size soon becomes prohibitive for most XML processors, and the need for internal reference spoils the elegance anyway.

In a fully relational DBMS it is simple to relate course data, player data and match data.  My own golf society website is SQL-driven, and I guess this is the solution most clubs and societies use.

So what are the advantages of an XML-based format?

1 ) It is an open, universal data schema

2 ) It is human-readable and easily edited

3 ) It can display data directly on a web page via a stylesheet

4 ) It can be transformed using simple tools into other data formats (including DB tables)

What are the disadvantages of an XML-based format?

1 ) It is difficult to manage large amounts of data (megabytes)

2 ) It is awkward to dynamically manage

The disadvantages only become apparent when managing scores and matches within a golfml document already packed full with course and player data.

The '3-document solution' (static course, semi-static player and dynamic score) is a practical response to the difficulties in implementing golfml in the real world.  Even a '2-document solution' (course+players, scores/matches) is helpful.  All documents are of course well-formed golfml files, and combined for different purposes when needed.

xinclude is one way.  I'll test the Apache cocoon engine to see if it is implemented.  There are other ways: google 'Include XML' to see them.

As a developer trying to use golfml I am simply pointing out real-world problems in current implementation.

:G

To post to this group, send email to golf-markup-language@googlegroups.com.
To unsubscribe from this group, send email to golf-markup-language+unsub...@googlegroups.com.

[minesadorada]

I just spotted another way to make flexible stylesheets from separate golfml documents.

It is the document() function which is implemented by most processors.  There's a good reference here: http://docstore.mik.ua/orelly/xml/xslt/ch07_02.htm

:G

[minesadorada]

OK  Here's an interim solution that CourseWriter is using.
It writes its own <application> section which includes the data necessary for a generic 'custom scorecard' stylesheet to use.

I think it conforms to the golfml specs OK, but would appreciate a check.

   <application name="golfml custom scorecard" dotname="com.charcodelvalle.golfmlclass" version="2.4.20120505" xmlns:golfmlclass="http://code.google.com/p/golfml">
      <golfmlclass:scorecard-stylesheet>coursescorecard.xsl</golfmlclass:scorecard-stylesheet>
      <golfmlclass:playerscorecard-stylesheet>playerscorecard.xsl</golfmlclass:playerscorecard-stylesheet>
      <golfmlclass:scorecard-css>golfml.css</golfmlclass:scorecard-css>
      <golfmlclass:handicap-system>ega</golfmlclass:handicap-system>
      <golfmlclass:units>meters</golfmlclass:units>
      <golfmlclass:course-name>Main Course</golfmlclass:course-name>
      <golfmlclass:tee-colour>yellow</golfmlclass:tee-colour>
      <golfmlclass:player-name>A.N. Other</golfmlclass:player-name>
      <golfmlclass:player-handicap>26.3</golfmlclass:player-handicap>
      <golfmlclass:last-updated>5-5-12 11:26:20</golfmlclass:last-updated>
</application>

[minesadorada]

I now have a 'generic' stylesheet that uses the application data in the post above.  It looks like this: http://www.charcodelvalle.com/golfmlweb/files/tenerife_amarillagolf.xml

[minesadorada]

For the coursedata stylesheet (static-course) I would like to be able to display a google map of the Country Club.

I have the structure:

  <country-club>

    <name>Abama Golf and Spa resort</name>

    <position>

      <gps alt="0" lat="0" lon="0"/>

    </position>

 ....

</country-club>

I am not very good at understanding the xsd, but I think it conforms...

The stylesheet can pick up the lat and lon attributes and call the google map API to display a map.

:G

[minesadorada]

I think I have gone as far as I want to with CourseWriter and scorecard stylesheets. The gps tags work fine. Only addition I could do would be to let the sylesheet recognise and display yardage bitmapped image files if they are present.  The kml/svg route is too fiddly for me.

Progress: Generic Scorecard here and Custom Scorecard here.

Future development would be:

1 ) PlayerWriter (Lazarus class/app)

This would be able to create/edit a golfml file of player information.

2 ) ScoreWriter (Lazarus class/app)

Using a golfml course info file and a golfml player file it would write/edit matches and scores.

I need to experiment with the advisability of using separate vs. unified golfml files to keep the course, player and score information.  Separate files could be combined as needed via a simple app (physical) or perhaps the stylesheet (virtual)