Hi Sandy, I prepared my draft project proposal and you can find it in the Xerces wiki[1]. Please give me your feedback on that, specially about the content of the "Description" section. Looking forward to your suggestions Thanks in advance. [1] http://wiki.apache.org/xerces/ishanjayawardena/scd_proposal <http://wiki.apache.org/xerces/ishanjayawardena/scd_proposal> On Tue, Mar 23, 2010 at 1:46 AM, Sandy Gao <[email protected]> wrote:
> Ishan, > > This looks quite promising. You are definitely on the right track. Some > quick comments: > > - The set of methods look good. Wondering about the flavours with and > without the namespace context. I tend to think the context is needed in > most/all cases (as you don't know whether some prefix is used in the SCP > string). > - I'm not sure where the methods should go. Need to give it some thought. > As you pointed out, they could be on a new interface, on XSModel, or (for > some of them) on XSObject. It should be fairly easy to change the interface > once we understand how the impl is done. So it doesn't have to be nailed > down now. > - Schema 1.0 is a good starting point. Ideally (time permitting) we also > want to work on schema 1.1 models, which are more complex and may help to > identify impl or even spec errors. The XSModel interfaces haven't been > updated to support new 1.1 constructs. That would be a prerequisite if we > want SCD/SCP for schema 1.1. > - We have started the work on constructing and resolving canonical SCPs and > we expect to have some initial work done before/around the summer. So you > may want to focus more on the part that resolves non-canonical paths. We can > talk more later about the interface/integration/work-division, once we have > the GoS stuff figured out. (Submitted/approved etc.; I'm new to the process, > BTW.) > > As for the proposal, I think what you have below covers most of it. It > would be nice if you could spend a little time thinking about the impl > strategy. Doesn't need to be very detailed, but high level interaction/data > structure design. That should be (more than?) sufficient. > > > 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-03-19 02:13:12 AM: > > > [image removed] > > > > Re: SCD implementation > > > > Ishan Jayawardena > > > > to: > > > > j-dev > > > > 2010-03-19 02:14 AM > > > > > Please respond to j-dev > > > > 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 > > Member, W3C SML WG > > (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] > > > > >
