- From: Eric Sirois <esirois@ca.ibm.com>
- Date: Wed, 18 Apr 2007 09:36:18 -0400
- To: George Cristian Bina <george@oxygenxml.com>
- Cc: Zafar Abbas <Zafar.Abbas@microsoft.com>, "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
Hello George,
Just to clarify. Do I need the .NET 2.0 Framework or the SDK in order for
oXygen to pick up the .NET 2.0 parser?
Kind regards,
Eric
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Blue Pages (Internal)
"Transparency and accessibility requirements dictate that public
information and government
transactions avoid depending on technologies that imply or impose a
specific product or
platform on businesses or citizens" - EU on XML-based office document
formats.
George Cristian
Bina
<george@oxygenxml To
.com> Eric Sirois/Toronto/IBM@IBMCA
cc
04/18/2007 09:29 Zafar Abbas
AM <Zafar.Abbas@microsoft.com>,
"xmlschema-dev@w3.org"
<xmlschema-dev@w3.org>
Subject
Re: redefine and interoperability
problems
Hi Eric,
If you have .NET 2.0 installed on that machine oXygen should use that.
Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Eric Sirois wrote:
> Hello Zafar,
>
> I'm using Oxygen 8.1. It looks like it using .NET 1.1. I'm not sure how
or
> if I can change the parser to .NET 2.0. If someone know how, that would
> be great. Otherwise, I'm stuck with what it provides, for now.
>
> Eric
> Eric A. Sirois
> Staff Software Developer
> DB2 Universal Database - Information Development
> DITA Migration and Tools Development
> IBM Canada Ltd. - Toronto Software Lab
> Email: esirois@ca.ibm.com
> Blue Pages (Internal)
>
> "Transparency and accessibility requirements dictate that public
> information and government
> transactions avoid depending on technologies that imply or impose a
> specific product or
> platform on businesses or citizens" - EU on XML-based office document
> formats.
>
>
>
> Zafar Abbas
> <Zafar.Abbas@micr
> osoft.com>
To
> Eric Sirois/Toronto/IBM@IBMCA,
> 04/13/2007 08:01 Michael Kay <mike@saxonica.com>
> PM
cc
> "'W. Eliot Kimber'"
> <ekimber@innodata-isogen.com>,
>
Subject
> RE: redefine and interoperability
> problems
>
>
>
>
>
>
>
>
>
>
> Eric,
> The circular group reference error you are seeing in .NET would be with
> .NET 1.1. This issue has been fixed in .NET 2.0 where you should not see
> that error. Let me know if you have any questions.
>
>
> Thanks,
> Zafar Abbas
>
> -----Original Message-----
> From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
On
> Behalf Of Eric Sirois
> Sent: Friday, April 13, 2007 6:59 AM
> To: Michael Kay
> Cc: 'W. Eliot Kimber'; xmlschema-dev@w3.org
> Subject: RE: redefine and interoperability problems
>
>
> Unfortunately, for the DITA XML Schemas we had to make use of
> <xs:redefine> in order to replicate substitutionGroups to avoid making
use
> of XML Schema inheritance mechanism. At the moment, there are two issues
> with make it hard for folks to use of the mechanism across most/all XML
> parsers. It's mainly the inconsistency between implementations.
>
> MSXML .NET - returns an error when including a self-reference to the
group
> when extending.
> Xerces-C - must redefine the schema document where the component to be
> redefined is defined. There is a bug against Xerces-J open at the moment
> https://issues.apache.org/jira/browse/XERCESJ-1219.
>
> This defect will make Xerces-C and Xerces-J behave in the same manner -
> redefine before it's included. Jirka's example using Xerces-C would
thrown
> an error stating something to the effect that the component is defined in
> the schema document that is referenced.
>
> I've asked our XML Schema representative to add some clarification to
spec
> regarding the order in which need to occur when redefining components.
> (redefine/include vs. include/redefine). It may be that once the spec
has
> a bit more clarity this defect will away or there will a lot of users who
> will have schemas that are no longer valid.
>
>
> Kind regards,
> Eric
> Eric A. Sirois
> Staff Software Developer
> DB2 Universal Database - Information Development
> DITA Migration and Tools Development
> IBM Canada Ltd. - Toronto Software Lab
> Email: esirois@ca.ibm.com
> Blue Pages (Internal)
>
> "Transparency and accessibility requirements dictate that public
> information and government
> transactions avoid depending on technologies that imply or impose a
> specific product or
> platform on businesses or citizens" - EU on XML-based office document
> formats.
>
>
>
> "Michael Kay"
> <mike@saxonica.co
> m>
To
> "'W. Eliot Kimber'"
> 04/05/2007 04:41 <ekimber@innodata-isogen.com>,
> AM <xmlschema-dev@w3.org>
>
cc
> Eric Sirois/Toronto/IBM@IBMCA
>
Subject
> RE: redefine and interoperability
> problems
>
>
>
>
>
>
>
>
>
>
>>> I personally think xs:redefine is one of those facilities
>> (xsi:nil is
>>> another) where you're better off pretending it doesn't exist.
>>> Implementors don't have that luxury, but users do.
>> Hmm. The DITA schemas depend entirely on xs:redefine in order
>> to provide the equivalent configurability to the parameter
>> entities in the DTD versions, that is, using schemas can
>> redefine the members of groups that are then referenced from
>> the used schemas.
>
> I have successfully tackled that problem by writing code that transforms
> schemas (or near-schemas) to provide the configurability. I think it's
> better to have this kind of capability in a separate language (indeed, a
> separate architectural component of the system) rather than building in
> self-modification semantics to the language itself.
>
> I would have thought that the configurability you describe above could be
> achieved by the even simpler technique of URI-switching - that is,
> redirecting the URI in an xs:include to refer to a selected variant of
the
> included module.
>
> xs:redefine is particularly horrible once schemas start to have wider
scope
> than a single validation episode, specifically, when multiple variants of
a
> schema component have to coexist. In particular, if you've got an XML
> database whose contents are described by a family of schemas, the notion
> that xs:redefine is "pervasive" could be taken to mean that it
effectively
> alters schemas that are used in a quite unrelated part of the database,
> including schemas describing documents that were stored years ago. That's
> clearly untenable; but finding a different definition of "pervasive" that
> actually works in this environment isn't easy. Saxon's approach is to say
> that once a schema component has been "used" (in some carefully defined
> sense) further redefinition is banned.
>
> (Having said that, this problem affects any technique that leaves you
with
> multiple versions or variants of a schema component coexisting. I think
> Roger Needham once said that all problems in computer science can be
solved
> by adding another level of indirection; and certainly the problem of
> handling multiple coexisting versions of schema components appears
> insoluble
> without adding a version/variant qualifier to the name of the component.)
>
> Michael Kay
> http://www.saxonica.com/
>
>
>
>
>
>
>
>
Received on Wednesday, 18 April 2007 13:36:33 UTC