Hi Sandy and Mukul, I would like to continue working on SCD implementation idea. Therefore I need to know your opinion about its expected behavior and implementation details etc.
First, let me summarize the discussion we had so far on SCD, We are only interested in relative SCD(RSCD) resolving capability for Xerces, given that there's no defined means to resolve a URI to a schema. Based on this, the two basic operations required by the implementation are, 1. to resolve a relative SCD. i.e. given a schema and an RSCD as the inputs, return a list of schema components. 2. to obtain the canonical SCP of a schema component (if available). i.e. given a schema component and the schema that contains the component along with the necessary namespace bindings as the inputs, return the canonical SCP Apart from that, another type of SCPs defined in the W3C SCD spec is the incomplete SCPs[1]. An incomplete SCP can be evaluated against a given schema component to retrieve a set of schema components within it(i.e similar to the way an RSCD is evaluated relative to a given schema, an incomplete SCP can be evaluated relative to a given schema component). Therefore based on the above two operations and the incomplete SCP resolving capability, we can suggest following essential operations for the SCP interface. XSObjectList resolveSCP(String scp, XSModel schema, NamespaceContext nc) XSObjectList resolveSCP(String scp, XSModel schema) XSObjectList resolveIncompleteSCP(String scp, XSObject component, NamespaceContext nc) XSObjectList resolveIncompleteSCP(String scp, XSObject component) String getCanonicalSCP(XSObject component, XSModel schema, NamespaceContext nc) Do you think that these methods satisfy the intended API for SCP? Where should these methods go in the actual implementation? In a separate interface (i.e something like "interface SCP" ?) or should they be added as extensions for existing interfaces, for example in XSModel and XSObject etc.? In addition to that, at the first stage, is it ok to implement the parser and the evaluator to support only XML schema 1.0 object model? I am planning to come up with a more loosely coupled desing, specially for SCP resolving feature so that the system will be more modular and easier to extend and maintain. The main reson for this is that according to the spec, SCPs have many usages other than in SCDs as long as they are used with proper namespace bindings. Therefore having a better desing for SCP would yield a number of additional requirements as well. So, I would like to know to what extent I'll have to include these implementation and desing details in my project proposal and if you have any suggestions please let me know because I'm looking forward to your feedback. Thanks in advance. [1] See Section 4.3.1 *Incomplete Schema Component Paths*: http://www.w3.org/TR/xmlschema-ref/#section-path-interpret On Fri, Mar 5, 2010 at 12:58 AM, Sandy Gao <[email protected]> wrote: > Ishan, > > Difference between a schema vs. a schema document: > > * Schema > > I am a schema, I have a global element declaration named "root" in > namespace "ns1", and its type is "myType" in namespace "ns2". "myType" is > derived from the schema built-in type "int" by specifying a maxInclusive > facet of 100. > > * Schema document > > I am an <xs:schema> element, I have an attribute named "targetNamespace" > whose value is "ns1". I have a child element <xs:element>. The child has an > attribute named "name" whose value is "root". It also has an attribute named > "type" whose value is "p2:int". It also has a namespace declaration that > associates the prefix "p2" with the namespace "ns2". > > I am another <xs:schema> element, with attribute targetNamespace="ns2", > child <xs:simpleType>. <xs:simpleType> has name="myType", child > <xs:restriction>, with attribute base="xs:int", ... > > > Now you can see the difference. Schema is an abstraction: it's a collection > of schema components. Each component has its properties, like name, type, > etc. And schema document is one way to represent a schema using XML syntax. > A schema may be assembled from one or more schema documents (or it could be > built without schema documents). > > For a SCD/SCP that says "give me the global element declaration for name > {ns1}root", we should return the element declaration in the schema (an > XSElementDeclaration object), and not the <xs:element> element in the schema > document. > > > Now about the absolute part of the SCD for identifying the schema. For a > given absolute URI (e.g. http://abc.def/xyz), there is no standard way to > know which schema it's pointing to. Dereferencing the URI will return you a > sequence of bytes (maybe some kind of file), but that's not a schema. The > association of the URI with a schema has to be done through magic: in my > system, I *know* this URI corresponds to that schema (e.g. that XSModel > object). > > In the example from the spec, it's assuming that, in that particular > environment, http://example.org/schemas/po.xsd corresponds to a particular > schema. It may be that that schema is assembled from loading the schema > document at "http://example.org/schemas/po.xsd";, but that's the knowledge > only meaningful in that system, and not an established standard. > > This is exactly why I suggested > > > "It'll be useful, IMO, to focus more on relative SCDs (and SCPs in > particular), than absolute SCDs." > > e.g. our SCD interface could have methods like: > > String getCanonicalSCP(XSObject component, XSModel schema, NamespaceContext > nc); > XSObjectList resolveSCP(String scp, XSModel schema, NamespaceContext nc); > > instead of > > String getCanonicalSCD(XSObject component, XSModel schema); > XSObjectList resolveSCD(String scd); > > The first 2 methods assume that the association between the absolute URI > and the schema is done (hence the XSModel is available). The latter 2 > methods operate on absolute SCDs, and will suffer from the problem of not > knowing how to construct/resolve the absolute URI for the schema. > > > Thanks, > Sandy Gao > XML Technologies, IBM Canada > Editor, *W3C XML Schema WG* <http://www.w3.org/XML/Schema> > Member, *W3C SML WG* <http://www.w3.org/XML/SML> > (1-905) 413-3255 T/L 313-3255 > > > Ishan Jayawardena <[email protected]> wrote on 2010-02-27 05:49:42 AM: > > > [image removed] > > > > Re: SCD implementation > > > > Ishan Jayawardena > > > > to: > > > > j-dev > > > > 2010-02-27 05:50 AM > > > > Please respond to j-dev > > > > Hi Sandy, > > I think more clarification is needed about the association among the > > terms, "the schema", "a schema document", and an absolute SCD. The > > spec defines the absolute SCD in the following way, > > "An absolute schema component designator identifies a particular > > schema component; it consists of two parts: a designator for the > > assembled schema (a schema designator), and a designator for a > > particular schema component or schema components relative (a relative > > schema component designator) to that assembled schema." > > But at the same time, it gives > > "http://example.org/schemas/po.xsd#xscd(/type::purchaseOrderType)" as > > an example for an absolute SCD. Obviously, the first URI part refers > > to a schema document, not to a schema but the definition mentions it > > to be an assembled schema. > > Also, you say that, > > > > > - 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. > > > > So according to you, the URI part doesn't need to be something like > > 'http://example.org/schemas/po.xsd' because it has to be a URI for an > > assembled schema. Can you please help me clarify the correct > > interpretation of absolute SCD? Why do you say that there's no defined > > way to resolve a URI to a schema? Here, are you reffering to the > > capability of Xerces of resolving a URI to a schema? > > Thanks in advance. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > >
