Thanks Al. Again, my concern is that we have an explicit
reference in the spec to an undefined XML Schema complex type. Clients or
validators using WC3 XML schema will just have to use "the right"
atom.xsd, and there is no mention in the spec of what that is . Lets discuss
this one briefly on Mondays call, although given the silence on this issue, I
can only assume that the TC understands and is satisfied with the solution in
draft 5.
Norrie
From: Al Brown
[mailto:albertcbrown@us.ibm.com]
Sent: Tuesday, January 05, 2010 9:14 AM
To: Quinn, Norrie
Cc: cmis@lists.oasis-open.org
Subject: RE: [cmis] CMIS-596 / cd05 update
Done. The change is a less invasive change than xs:any and was possible in
the short timeframe. I am looking forward to discussing it on the call
>As I stated
in CMIS-596, I think that the solution in draft 5 is problematic as
atom:feedType is not defined anywhere. It >works with a JAXB client that is
using an atom XML Schema with a complex type named feedType, but might not work
with >a binding framework client using another Atom schema. It also might be
problematic for XML validation.
Not sure I understand this point. The current model is agreement with XML
Schema. Please see 2.6.1 in http://www.w3.org/TR/xmlschema-1/.
Since xsi:type is a supported part of XML Schema I am not sure how it
causes problems for XML validation. If you know of concrete examples of where
it does cause problems, I'd like to see so we can fix it.
I've quoted 2.6.1 here:
2.6.1 xsi:type
The Simple Type Definition (§2.2.1.2) or Complex Type Definition (§2.2.1.3) used in ·validation· of an element is usually determined by reference to the appropriate
schema components. An element information item in an instance may, however,
explicitly assert its type using the attribute xsi:type.
The value of this attribute is a ·QName·; see QName Interpretation (§3.15.3) for the means by which the ·QName· is associated with a type definition.
Best & Happy New Year,
-Al
Al Brown
Office 714 327 3453
Mobile 714 251 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments,
are confidential and are intended solely for the use of the person or entity to
whom the message was addressed. If you are not the intended recipient of this
message, please be advised that any dissemination, distribution, or use of the
contents of this message is strictly prohibited. If you received this message
in error, please notify the sender. Please also permanently delete all copies
of the original message and any attached documentation.
---01/04/2010 07:33:35 PM---Al,
From: <Quinn_Norrie@emc.com>
To: Al Brown/Costa Mesa/IBM@IBMUS, <cmis@lists.oasis-open.org>
Date: 01/04/2010 07:33 PM
Subject: RE: [cmis] CMIS-596 / cd05 update
Al,
Can you please
update CMIS-596 with the proposal/solution that was implemented in draft 5:
http://tools.oasis-open.org/issues/browse/CMIS-596
As I stated in
CMIS-596, I think that the solution in draft 5 is problematic as atom:feedType
is not defined anywhere. It works with a JAXB client that is using an atom XML
Schema with a complex type named feedType, but might not work with a binding
framework client using another Atom schema. It also might be problematic for
XML validation.
I just want to
make sure that the TC understands that we do not have the simple xs:any based
solution documented in JIRA immediately after this was discussed in the last TC
call.
Norrie
From: Al Brown [mailto:albertcbrown@us.ibm.com]
Sent: Thursday, December 24, 2009 12:12 AM
To: cmis@lists.oasis-open.org
Subject: [cmis] CMIS-596 / cd05 update
I spent a good part of today updating
examples for the switch to web services model for cmisra:children.
Unfortunately, this is quite a large change and loses some of the atom-ness of
the binding. For example, no link relations would be available as atom:entry is
no longer used. This is quite a negative in my opinion.
As such, I switched back to the earlier proposal of removing atom.xsd from the
CMIS-RestAtom.xsd. All bindings will have to add the attribute xsi:type="atom:feedType"and define the atom namespace on an earlier enclosing
element. If this is not there, no client or server can parse cmisra:children as
the hint that that element is an atom:feedType is no longer in
CMIS-RestAtom.xsd. This works with jaxb clients and servers.
I've posted cd05 to kavi. If an alternative is desired to above we will need to
meet and discuss how we would like to approach this.
Best and Happy Holidays!
-Al
Al Brown
Office 714 327 3453
Mobile 714 251 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments,
are confidential and are intended solely for the use of the person or entity to
whom the message was addressed. If you are not the intended recipient of this
message, please be advised that any dissemination, distribution, or use of the
contents of this message is strictly prohibited. If you received this message
in error, please notify the sender. Please also permanently delete all copies
of the original message and any attached documentation.