[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