Hi Sandy, Even if I suggested two main types of methods( i.e altogether five methods) for the SCD API, I think only the implementation of the first four methods would be suitable for a project when we consider time constrains. This will also help us come up with more realistic and measurable milestones because when I tried to create a project schedule, I noticed that I didn't have a clear understanding about the amount of work and required/available time to implement the method getCanonicalSCP() and where to put its details in the schedule. What is your opinion about this? Do you believe that this method too can be implemented along with the other methods within available time with out any problem? Should I include it in the proposal? And do you still believe these incomplete SCP resolving capability also can be implemented once we are done with the two main components of the project; the SCP parser and the evaluator, within given time? Right now, what I am thinking is that once we complete the parser and the evaluator, we will have enough time only to implement the resolveSCP() method which is the main operation of our project. Do you agree with that? Can you tell me exactly what methods should I mention in my proposal. Currently, these are the four methods that I am suggesting for our API
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) You've also told me to focus more on implementing resolving non-canonical SCPs. So, do these methods require any modification to reflect that? (I mean when these are going to be included in the proposal, in what way should I modify these methods so that they show that I am implementing them to resolve non-canonical paths?) Thanks in advance. 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] > > > > >
