Schemas and examples

There has been a lot of side-talk, and a lot of rumbling and side messages in the last 24 hours, so let me address this issue flat on.

Inside the IETF draft RFC standard XXML serialization for Icalendar, every component has a set of optional parameters and properties. Each parameter and property is optional, meaning it is legal to have an empty :parameter: object schedule-related communications . We do not use most of the properties in EMIX, and those we do, we use rarely. This means that the original raw artifacts have plenty of empty property artifacts.

<?xml version="1.0"?>

<emix:product xmlns:emix="http://docs.oasis-open.org/ns/emix" xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xmlns:res="http://docs.oasis-open.org/ns/emix/power/resource" xmlns:power="http://docs.oasis-open.org/ns/emix/power">

<xcal:properties/>

<xcal:components>

<xcal:gluon>

<xcal:properties>

<xcal:uid>

<xcal:parameters/>

<xcal:text>96eb162c-21f2-4ec0-8c1c-4a349e49b74c</xcal:text>

</xcal:uid>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/New_York</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>20110315T00000000</xcal:date-time>

</xcal:dtstart>

<xcal:duration>

<xcal:parameters/>

<xcal:duration>PT0H</xcal:duration>

</xcal:duration>

<xcal:x-wsCalendar-attach>

<xcal:parameters/>

<emix:productDescription xs:type="power:fullRequirementsPower">

<power:contractType/>

<power:serviceLocation>

<power:node>xxxnode.idxx</power:node>

</power:serviceLocation>

<power:charges/>

<emix:priceAbsolute>

<emix:priceEnumeration>0.115</emix:priceEnumeration>

</emix:priceAbsolute>

<power:Watts>

<emix:scale>#M</emix:scale>

<power:powerAttributes>

<power:hertz>60</power:hertz>

<power:voltage>220</power:voltage>

<power:ac>false</power:ac>

</power:powerAttributes>

</power:Watts>

<power:maximumPower>10000</power:maximumPower>

<power:minimumPower>0</power:minimumPower>

</emix:productDescription>

</xcal:x-wsCalendar-attach>

</xcal:properties>

<xcal:components/>

</xcal:gluon>

</xcal:components>

<emix:currency>USD</emix:currency>

<emix:marketContext/>

<emix:transactiveState>PricePublication</emix:transactiveState>

<emix:constraints>

<emix:constraints/>

<emix:requirements/>

</emix:constraints>

</emix:product>

During pre-publishing review, it was frequently comments that these were distracting. They were published with these missing (I created an automatic pruning script to remove empty branches from the tree.) The intended purpose for these examples was for inclusion in the narratives of the specification. In the OASIS process, all such examples are non-normative. It seems to those consulted that it was better to remove them to improve clarity.

I must admit I was blind-sided by those whose response is load the sample into XMLSpy and if it pukes, stop reading. Note that LiquidXML and JAX both handle the absence of missing nodes with no required children as legal. Quite frankly, the perfect accuracy of non-normative artifacts was not on my radar. It seemed as unlikely as spell-checking the comments in a new EAP file distributed and stopping reading at the first spelling error. There is no problem re-producing the samples with all the noise intact, for they are auto-generated already.

The committee may want to consider a more serious response to handling this sort of non-normative issue. In particular, following NIEM guidelines, and the strong guidance from the Tiger Team, we have moved toward using substitution groups across the board. The handling of Substitution groups represent a known bug in EA. If we can use no artifacts that break in a single tool, whether correctly or not, we will find our information models much larger, much more confusing, and much harder to read. We will also find it difficult to comply with NAESB and NIEM guidance.

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.

Toby Considine
TC9, Inc

OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

emix message