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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Schema


A great big thanks goes to Dave Richards of Trane for producing and taking ownership of the schema for the Sys service.  He's done a great job!

Here are some of his notes concerning the schema and specification:

1)	Section 2.5.1:  Why disallow “0” and “1”?  Seems easier to just use xs:boolean than to restrict it.  I did not do the restriction in my schema.
2)	Section 2.6.8 should be called “unit” to be consistent with element name.  Paragraph text should be changed as well.
3)	Section 2.6.8 – last sentence should reference 2.7 rather than 2.6.
4)	Section 3.2.6 – why is there a service element with nothing but an id element?  Seems like we could eliminate one or the other.
5)	Section 4.2.2 – wasn’t sure exactly what the ext element does or how to accurately represent the fact that the result can be an ext from other namespaces.  I made it accept any element from another namespace, which is not right.
6)	Section 4.2.2 – children description should say “if the request…” not “is the request…”
7)	Section 5.1.2 – can a write element have both a value and an object child?  Seems like it could.  Also, why is there no analog of the object/sub-object in the read service to avoid repeating full paths?
8)	One  issue with the schema is whether we want all types explicitly named or whether the anonymous types are OK.  Some WSDL importers seem to have issues with nested anonymous types.
9)	For the read result, do we want the generic <object> with the choice of value elements or do we want to create typed result objects?  The typed objects would allow us to specify which facets are allowed for the various types.  They would also allow a substitution group which is somewhat more flexible than the choice group.

Dave and I agree that the simple data types shouldn't be top level elements.  Recommendations?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]