[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] More comments on Tag Structure paper
This explanation makes a ton of sense to me. Let's call this the #1a option: it's still extremely structured, but it leverages XSD smarts rather than having the whole thing wedged into the instance. I'm assuming that object classes and representation types have to be almost perfectly consistent to work properly in option #1. Option #2, as presented to us, was a more "artistic" approach to the problem. This option #1a is still regular and has all the benefits we outlined in our last meeting, but seems to result in friendlier instances. Is there any reason to suspect that things won't fall out this nicely for option #1a, e.g., because our type hierarchies can't be done so neatly? Would somebody be willing to take the first 10 or 20 "entity names" in the Library Content work and attempt to convert them to a #1a style? Eve At 06:29 PM 11/26/01 -0800, Dave Carlson wrote: >Also, Mike, if I understand another one of your comments, the "Party" >and "Measure" are actually datatype information that is appended to >the tag name. This seems really wrong to me. The datatype of patient >and weight are defined in the schema. So, why not: > ><patient> > <weight> > </weight> ></patient> > >And the schema would have: > ><xsd:element name="patient" type="Party"/> ><xsd:element name="weight" type="Measure"/> > >where the Party and Measure are presumably defined as xsd:simpleType >datatypes. -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC