Ideas for New Schema

Jan 1, 2008 at 10:34 PM
If you have any suggestions for additional schema that should be added to the standards, please post them here
Feb 15, 2008 at 3:33 PM
David: I've been developing and testing the 3.2 schemas with ODI assuming they are the current production schemas. When a new version is released, is there a good way to know what changed so we can adjust our systems accordingly?
Feb 15, 2008 at 9:20 PM
David - Would it be possible to zip-up and post each group of schemas and documents? That would make it easier to download all schemas when needed. Thanks - Karyn Bliss
Feb 20, 2008 at 7:14 PM
This is an idea for a change to the "root" AAAA's part of all of the schemas. I'm putting it here as there is no other forum currently available.

We'd like to suggest adding a messageDescription field to the root area. This would contain identifying information about the particular document. For instance, an Order document would have the agency and order number, an Avail the station and avail number. An application could then be written without knowledge of every schema and would be used by Client Support personnel to search for specific documents. They would use this field to search for specific orders, avails, invoices, etc. that don't reach their final destination… (of course this may never happen and everything will always work fine.) We know that the information we are suggesting be put in the messageDescription field is also in the document; but this way, there would be a standard place for Gateway applications to find it and search/filter on it, and the app would not need to know about the type of document nor the specific schema to use to get it.

Below is a suggested layout. The messageDescription field would be text and consist of perhaps an ID# for the document and perhaps the "Type of Document". For instance -- "Order ID# AGY12345".


<CreateOrderRequest serviceName="CreateOrder"
originatingTradingPartner="2F9C0543-71CC-41bc-B7C6-59CD4047C624" messageExpiration="2007-04-16T09:27:47.0Z" timestamp="2007-04-15T09:27:47.0Z" messageVersion="3.2"
destinationTradingPartner="A0D151AD-DE9A-484b-A8AB-68F05E82C337" serviceInstanceId="74D300DF-4671-4297-9BAF-273D14EF0D52"
messageDescription=”type-of-message + ID + … “
xsi:schemaLocation=" TVBCreateOrderRequest_3.2.xsd"
xmlns="" xmlns:tvc="" xmlns:tvm="" xmlns:xsi="">
Mar 19, 2008 at 3:48 PM
Thanks for your input. All suggestions are being reviewed for our next release.
Apr 18, 2008 at 5:57 PM
Support for orbits needs to be enhanced to support spot quantities within the time ranges specified by the <ContractInterval> elements instead of the simple boolean true/false. This will allow for the ability to spread a set number of spots in a day to the designated programs airing in the specified Start/End time ranges.

The ability to assign the Maximum (and possibly Minimum) number of spots which can air on any given day for Weekly spot distribution. This allows spots to be focused around target days for a given campains "big event" while at the same time preventing all of the Weekly spots from being blown one day during the week.

The PrimaryDemoCategory is weak in it's implementation. There is nothing in the schema to enforce that a given buyline must contain the primary demographic. Even further, the remaining demographics are just a pool with no prioritization associated with them to identify which is more important to a buyer.
Apr 24, 2008 at 2:50 PM
DUNSNumber would make more sense being down at the address level as opposed to the Advertiser, Agency, Seller, etc level.

Especially since according to this web site;jsessionid=8A56CF69C076C710533A66160723A814

Dun & Bradstreet (D&B) provides a D-U-N-S Number, a unique nine digit identification number, for each physical location of your business.

Since a company can have multiple addresses the DUNS number should be tied to a particular address not at the corporate level.

May 22, 2008 at 2:55 PM
Does is really make sense to ever have more than one SpotOption on a Buyline?  The only reason I can come up with having multiple SpotOptions is if there are plans to combine options together.  Is this the intention?

The MakegoodRequest schema is weak in it's implementation of *Weekly Spots*.  There is no eligible days spot distributions associated with the spot quantity but there is in the case of daily spots.

There doesn't appear to be support for Program Names.  Not all buys are Time buys.  A spots buy by Program needs to have a Program Name associated with it.