Hi Sandy, Now you can see my modified proposal[1] I removed the sentence that described about considering existing implementation because I belieave we could implement this in a better way that is specific to us. Thank you for highlighting that.
In the extended primer example[2] of the spec, it's mentioned that when the schema doesn't have a target namespace, namespace bindings are not required for the SCPs. That's why I mentioned the need of the methods that don't take in the namespace context parameters and hope that it is more appropriate. Have you got more suggestions? Thank you [1] http://wiki.apache.org/xerces/ishanjayawardena/scd_proposal [2] http://www.w3.org/TR/2010/CR-xmlschema-ref-20100119/#section-primer-example On Wed, Mar 31, 2010 at 11:11 PM, Sandy Gao <[email protected]> wrote: > Ishan, > > The proposal looks very good. Great work! A few minor comments, nearly > knit-picking. > > "Please note that the term assembled schema (or schema or the schema > description schema component) refers to a resulting logical namespace that > is generated by the combination of one or more such schemas and these > schemas may be physically represented as schema documents." > > To be more precise, I would say "refers to a logical graph of schema > components. Schemas may be physically represented as schema documents". i.e. > - A schema doesn't necessarily correspond to a single namespace > - A schema isn't necessarily be generated from combining other schemas > > "It is obvious that if we try to evaluate that ASCD against the schema in > that URI, first we have to resolve that URI and build a schema from it, > which is not possible with Xerces." > > The URI "identifies" the schema, which isn't always the same as "can be > resolved and used to build the schema". The task of "building" a schema for > a given URI can sometimes be done. e.g. you can dereference the URI (URL) to > get the schema document, and assemble a schema from it. Xerces can also > handle this task well. The difficulties really lies in the "identification" > part. For an URI "http://example.org/schemas/po.xsd";, there is no standard > way to know what schema it identifies. > > > "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)" > > It would be beneficial to explain the distinction between the methods that > take a "NamespaceContext" parameter and those that don't. > > "... about how to navigate and XSModel is required." > > Typo. and XSModel -> an XSModel > > "I could also find couple of existing implementations of SCD[18][19] and > they will also be considered in designing the API where necessary." > > Understanding other efforts in this area is good. You may want to be > careful though in terms of getting contaminated with others' intellectual > property. Not all open source licenses are equally permissive/restrictive. > Just something to keep in mind. > > > 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 > > > [image: Inactive hide details for Ishan Jayawardena ---2010-03-30 05:04:20 > AM---Hi Sandy, I prepared my draft project proposal and you]Ishan > Jayawardena ---2010-03-30 05:04:20 AM---Hi Sandy, I prepared my draft > project proposal and you can find it in the Xerces > > > From: > Ishan Jayawardena <[email protected]> > To: > [email protected] > Date: > 2010-03-30 05:04 AM > Subject: > Re: SCD implementation > ------------------------------ > > > > 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> > <http://wiki.apache.org/xerces/ishanjayawardena/scd_proposal> > On Tue, Mar 23, 2010 at 1:46 AM, Sandy Gao > <*[email protected]*<[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]* <[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*<http://www.w3.org/TR/xmlschema-ref/#section-path-interpret> > > > > On Fri, Mar 5, 2010 at 12:58 AM, Sandy Gao > <*[email protected]*<[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*<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*<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*<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]* <[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)*<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*<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]*<[email protected]> > > > For additional commands, e-mail: > *[email protected]*<[email protected]> > > > > > >
<<ecblank.gif>>
<<graycol.gif>>
