You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Sandy Gao <sa...@ca.ibm.com> on 2010/02/23 23:38:13 UTC
SCD implementation
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
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
Thanks Sandy for your reply. That's so good and there's a lot of details
that I've been looking for.
On Fri, Mar 5, 2010 at 12:58 AM, Sandy Gao <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >
>
>
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi Sandy,
Thank you for your suggestions and highlighting some issues like the
intellectual property stuff because I really did not think about it before,
now I can modify the proposal in a better way and I'l let you know once I
complete it.
Thank you once again.
On Wed, Mar 31, 2010 at 11:11 PM, Sandy Gao <sa...@ca.ibm.com> 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 <ud...@gmail.com>
> To:
> j-dev@xerces.apache.org
> 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 <*s...@ca.ibm.com>>
> 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 <*udeshike@gmail.com* <ud...@gmail.com>> 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 <*s...@ca.ibm.com>>
> 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 <*udeshike@gmail.com* <ud...@gmail.com>> 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: *j-dev-unsubscribe@xerces.apache.org*<j-...@xerces.apache.org>
> > > For additional commands, e-mail: *j-dev-help@xerces.apache.org*<j-...@xerces.apache.org>
> > >
>
>
>
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com>
> To:
> j-dev@xerces.apache.org
> 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 <*s...@ca.ibm.com>>
> 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 <*udeshike@gmail.com* <ud...@gmail.com>> 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 <*s...@ca.ibm.com>>
> 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 <*udeshike@gmail.com* <ud...@gmail.com>> 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: *j-dev-unsubscribe@xerces.apache.org*<j-...@xerces.apache.org>
> > > For additional commands, e-mail: *j-dev-help@xerces.apache.org*<j-...@xerces.apache.org>
> > >
>
>
>
Re: SCD implementation
Posted by Sandy Gao <sa...@ca.ibm.com>.
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.
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255
From: Ishan Jayawardena <ud...@gmail.com>
To: j-dev@xerces.apache.org
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
On Tue, Mar 23, 2010 at 1:46 AM, Sandy Gao <sa...@ca.ibm.com> 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.
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255
Ishan Jayawardena <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org.
> > For additional commands, e-mail: j-dev-help@xerces.apache.org.
> >
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> > > For additional commands, e-mail: j-dev-help@xerces.apache.org
> > >
>
>
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> > > For additional commands, e-mail: j-dev-help@xerces.apache.org
> > >
>
>
Re: SCD implementation
Posted by Sandy Gao <sa...@ca.ibm.com>.
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.
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255
Ishan Jayawardena <ud...@gmail.com> 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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
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 <sa...@ca.ibm.com> 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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org
> >
>
>
Re: SCD implementation
Posted by Sandy Gao <sa...@ca.ibm.com>.
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 <ud...@gmail.com> 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: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: SCD implementation
Posted by Mukul Gandhi <mu...@apache.org>.
On Sat, Feb 27, 2010 at 10:49 AM, Ishan Jayawardena <ud...@gmail.com> wrote:
> When it comes to the implementation of SCD, we are going to need a
> Java object for this "assembled schema" but XSModel is defined as a
> Java interface. So how can we produce an object for this purspose? Can
> we use org.apache.xerces.impl.xs.XSModelImpl.java to create this
> object?
yes, we can construct the XSModelImpl (which implements the XSModel
interface, so you're actual working with XSModel) object from scratch
and add, schema components to it.
The constructor of, XSModelImpl looks like following:
XSModelImpl(SchemaGrammar[] grammars)
So, first you have to construct a SchemaGrammar object (or an array of
it) and add schema components to it, using the desired, add* methods.
But I suggest, that for SCD implementation, instead of constructing
XSModelImpl from scratch, you can you the XSLoader implementation to
construct a XSModel (ref,
http://xerces.apache.org/xerces2-j/javadocs/xs/org/apache/xerces/xs/XSLoader.html).
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi,
According to the SCD spec, a schema designator is a single URI for a
resource representing an assembled schema and this assembled schema
may have been assembled from one or more schema documents, etc. The
question I have is that if XSModel represents an assembled schema in
Xerces, in what way this 'single URI' is denoted in actual
programs(i.e. what type)? In other words, how does Xerces represent
this 'single URI' and how can we access it for programming purposes?
When it comes to the implementation of SCD, we are going to need a
Java object for this "assembled schema" but XSModel is defined as a
Java interface. So how can we produce an object for this purspose? Can
we use org.apache.xerces.impl.xs.XSModelImpl.java to create this
object?
Thanks.
On 2/25/10, Mukul Gandhi <mu...@apache.org> wrote:
> On Thu, Feb 25, 2010 at 4:10 PM, Ishan Jayawardena <ud...@gmail.com>
> wrote:
>> Hi mukul, to add something new to our discussion, the SCD spec also uses a
>> term called "an assembled schema". So with respect to the XSModel
>> implementation, does an XSModel object represent this "assembled schema" ?
>
> yes, Xerces XSModel represents an "assembled schema" as you've pointed
> to the SCD spec.
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: SCD implementation
Posted by Mukul Gandhi <mu...@apache.org>.
On Thu, Feb 25, 2010 at 4:10 PM, Ishan Jayawardena <ud...@gmail.com> wrote:
> Hi mukul, to add something new to our discussion, the SCD spec also uses a
> term called "an assembled schema". So with respect to the XSModel
> implementation, does an XSModel object represent this "assembled schema" ?
yes, Xerces XSModel represents an "assembled schema" as you've pointed
to the SCD spec.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi mukul, to add something new to our discussion, the SCD spec also uses a
term called "an assembled schema". So with respect to the XSModel
implementation, does an XSModel object represent this "assembled schema" ?
It is defined in the spec like this,
""An assembled schema forms a rooted graph of schema components and property
records, where certain schema component and property record properties
contain other schema components and property records as their values (or
part of their values)."
thanks.
On Thu, Feb 25, 2010 at 4:00 PM, Mukul Gandhi <mu...@apache.org> wrote:
> On Wed, Feb 24, 2010 at 10:19 AM, Ishan Jayawardena <ud...@gmail.com>
> wrote:
> > I don't get the difference between "a schema" and "a schema documet",
> when you say,
>
> >> 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.
> >
> > what is actually the difference between them?
>
> Sandy, is right. To me, "schema" is a generic term, representing a
> logical assembly of schema components (using notions like elements,
> attributes, cardinality and so on). We cannot identify a "schema" in a
> sense which Sandy explained, with a URI (in a standard way, as Sandy
> explained).
>
> Whereas, "schema document" is some physical representation of the
> schema (say a file on local file system, or a web server), which is
> normally identifiable with some URI.
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
Re: SCD implementation
Posted by Mukul Gandhi <mu...@apache.org>.
On Wed, Feb 24, 2010 at 10:19 AM, Ishan Jayawardena <ud...@gmail.com> wrote:
> I don't get the difference between "a schema" and "a schema documet", when you say,
>> 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.
>
> what is actually the difference between them?
Sandy, is right. To me, "schema" is a generic term, representing a
logical assembly of schema components (using notions like elements,
attributes, cardinality and so on). We cannot identify a "schema" in a
sense which Sandy explained, with a URI (in a standard way, as Sandy
explained).
Whereas, "schema document" is some physical representation of the
schema (say a file on local file system, or a web server), which is
normally identifiable with some URI.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: SCD implementation
Posted by Ishan Jayawardena <ud...@gmail.com>.
Hi Sandy,
Your post was so comprehensive and I could clarify many doubts that I had
about the implementation details of SCD and the relationship between XSModel
and schema.
> - 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.
>
This was so helpful for me to understand the purpose of XSModel. Also, there
are some points in your mail that I have to study more about and I don't get
the difference between "a schema" and "a schema documet", when you say,
> 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.
>
what is actually the difference between them?
Thank you.