All,
Some very interesting discussion in the "Serializing XSModel - more information needed" thread. The following are some of my thoughts on SCD. As you can see, a lot of them are to agree with what people has already said in the above thread. - SCD is to address "schema components", not schema documents or fragments of schema documents. Schema components are represented in Xerces using the org.apache.xerces.xs interfaces (XSModel and friends). So the primary SCD operations should on XSModels. XSModel is equivalent to the "schema description component" mentioned in the SCD spec. - Differences between SCD and SCP. SCD could be absolute, with an URI to identify the schema, and a fragment for the component(s) in that schema. Given that there is no defined way to resolve an URI to a schema (note: not a schema document), it'll often be difficult (and not very useful) to work with absolute SCDs. Relative SCDs have some "xmlns" parts for namespace bindings, and an "xscd" part for the "schema component path" (SCP). It'll be useful, IMO, to focus more on relative SCDs (and SCPs in particular), than absolute SCDs. - There are different scenarios where SCDs/SCPs could be useful. These are useful in guiding us to design the proper interfaces. The 2 primary operations should be: 1. Resolve a relative SCD. i.e. given an XSModel and a relative SCD, return a list of schema components. 2. Obtain the canonical SCP of a schema component (if available). i.e. given a schema component and the XSModel that contains the component, return the SCP (along with the necessary namespace bindings). Note that it's not canonical SCD, which is an absolute SCD. With the above 2, people can get a SCD/SCP from #2, pass it to some other parts of the system, and use #1 to interpret it to get the corresponding component(s). This should satisfy a lot of the SCD use cases. Thanks, Sandy Gao XML Technologies, IBM Canada Editor, W3C XML Schema WG. Member, W3C SML WG (1-905) 413-3255 T/L 313-3255
