[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Getting Back to Basics - How to describe Dates and Times andEvents?
> John McClure wrote: > > <Document xsi:type='ServiceDocument' name='Invoice"> > > <title xml:lang='EN'>Invoice</title> > > <identifier>ABC-12345</identifier> > > </Document> > > > > As good a techhead as Martin apparently is, the above is a far more > > intuitive encoding than > > > > <docRef > docType="http://www.ebXML.org/Messages/Invoice">ABC-12345</docRef> > > Intuition doesn't always work, sometimes you need to look at real payloads > and work out how to reduce them:-) > > The main difference between our approaches is in "how and where". In most > TPAs the docRef element will always point back to the same type of > information. Therefore the docType can be defaulted to in the DTD and > doesn't need to be part of the instance. With your scheme there > is no way to > default the type of reference for a particular TPA. My comments were originally directed at an accounting example -- an instance document -- not so much at the TPA. My objectives in picking at your code were not personal of course but more concerned with: 1. demonstrating that a 'docRef' element isn't needed in the first place 2. nudging people to see RDF in practice 3. showing how to include taxonomy on an element representing a resource Your comment about DTD-based mechanics surprises me. In an ebXML 'regRep' based architecture, I'd think that default values would be handled in some more elegant, sensible manner. In fact, I'd think that the official ebXML answer establishes an association between a set of default values and the ebXML concept of "contexts". With that in mind, perhaps you'd understand that my response is basically that the DCN architecture places default values into a dictionary, not into a DTD. I also believe that verbosity not be given such short shrift -- indeed, the design precepts of XML itself specifically discount the importance of non-verbose datastreams -- a necessary mandate given the self-describing nature of the language.
Powered by eList eXpress LLC