OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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?


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:
>   <weight>
>   </weight>
>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

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