Valsalan, Unnikrishnan | 1 Aug 13:02 2007

XSD - Difference between element ref and element type

Hi experts,

   Could someone here please explain me the difference between these two
ways of defining elements,

<xsd:element name="aggregateElement" type="base:baseType"/>

<xsd:element ref="base:baseElement"/>

The only difference that I could understand is the one specified in this
article [1], which says that during an import, 
elements created with ref retains the Namespace of the schema from which
it is imported.

That seams to be an obvious difference. I am not clear on when to use
*type=* style and when to use *ref=* style.

Thanks in advance for any help,

Regards,

Unni.

[1] -
http://developers.sun.com/jsenterprise/nb_enterprise_pack/reference/tech
art/namespaces2.html

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
(Continue reading)

Boris Kolpackov | 1 Aug 14:54 2007

[ANN] CodeSynthesis XSD 3.0.0 - Open-source XML Schema to C++ compiler

Hi,

I am pleased to announce the availability of CodeSynthesis XSD 3.0.0.

CodeSynthesis XSD is an open-source (GPL2 + proprietary license), cross-
platform W3C XML Schema to C++ data binding compiler. Provided with a
schema, it generates C++ classes that represent the given vocabulary as
well as parsing and serialization code. You can then access the data
stored in XML using types and functions that semantically correspond to
your application domain rather than dealing with elements, attributes,
and text in a direct representation of XML such as DOM or SAX.

XSD supports both in-memory and stream-oriented processing models by
implementing two C++ mappings: C++/Tree and C++/Parser. The C++/Tree
mapping represents the information stored in XML instance documents
as a tree-like, in-memory object model. The C++/Parser mapping
generates parser skeletons for data types defined in XML Schema. Using
these parser skeletons you can build your own in-memory representations
or perform immediate processing of XML documents.

Major new features in this release:

 C++/Tree:

  * Generation of documentation in the Doxygen format.
  * New XML Schema wildcards mapping which represents the matched
    content as DOM fragments.
  * Support for binary serialization in the XDR format.
  * Support for polymorphic binary serialization.
  * New Getting Started guide.
(Continue reading)

Boris Kolpackov | 1 Aug 15:05 2007

Re: XML DTD/XSD parser library sought

Hi Jeremy,

"Jeremy H. Griffith" <jeremy <at> omsys.com> writes:

> I'm looking for a parser library in C/C++ with which I can
> read fairly complex DTDs (like those for DITA and DocBook)
> and extract content models for all elements for further
> analysis and manipulation.

I know Xerces-C++ has robust DTD handling code with an
in-memory grammar model which I believe you can navigate.

> Doing the same for XSD schemas would be nice, but is less
> important.

Again, Xerces-C++ supports this. Or you can use our
libxsd-frontend[1] which is a compiler frontend for XML Schema.
It provides the XML Schema semantic graph as well as the
traversal mechanism. We use it in the implementation of
our XML Schema to C++ compiler[2].

[1] http://www.codesynthesis.com/projects/libxsd-frontend/
[2] http://www.codesynthesis.com/products/xsd/

hth,
-boris

--

-- 
Boris Kolpackov
Code Synthesis Tools CC
(Continue reading)

Fraser Goffin | 2 Aug 17:28 2007

Re: XSD - Difference between element ref and element type

the 'type' attribute is a reference to a simple or complex type declaration whereas the 'ref' attribute references a global element declaration
 
Fraser.
 
On 01/08/07, Valsalan, Unnikrishnan <unnikrishnan.valsalan <at> fmr.com> wrote:
Hi experts,

  Could someone here please explain me the difference between these two
ways of defining elements,

<xsd:element name="aggregateElement" type="base:baseType"/>

<xsd:element ref="base:baseElement"/>

The only difference that I could understand is the one specified in this
article [1], which says that during an import,
elements created with ref retains the Namespace of the schema from which
it is imported.

That seams to be an obvious difference. I am not clear on when to use
*type=* style and when to use *ref=* style.

Thanks in advance for any help,

Regards,

Unni.

[1] -
http://developers.sun.com/jsenterprise/nb_enterprise_pack/reference/tech
art/namespaces2.html


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


Philippe Poulard | 2 Aug 20:28 2007
Picon
Picon

Re: XML Diff

Fraser Goffin a écrit :
> Has anyone come across a good Java library for comparing XML instances ?
>  

hi,

you should consider XUnit :
http://reflex.gforge.inria.fr/xunit.html

XUnit does the same than JUnit, but if you have to compare 2 XML 
documents, it might help ; usually you do you own stuff that produce 
some datas, and as you have prepared the expected datas, you just have 
to assert that the 2 datas are equals ; this is the same in XUnit, and 
the 2 datas can be 2 nodes

for example :
<xunit:test-case name="myTest" label="Testing purchase order">
     <!--run your own stuff-->
     <acme:transform-purchase-order output="result.xml" id="1234"/>

     <!--retrieve the result and the output expected-->
     <xcl:parse name="po" source="result.xml"/>
     <xcl:parse name="oe" source="output-expected.xml"/>

     <!--check if they are equals-->
     <xunit:assert-node-equals result="{ $po }" expected="{ $oe }" 
recurse="true"/>
</xunit:test-case>

the tool works on the DOM, and it will report each difference found (for 
example when an attribute is missing, or when an attribute is not 
expected, or when the attribute values don't match) ; at a given level, 
if 2 elements don't match, the tool won't look inside their content

exemple of report :
http://reflex.gforge.inria.fr/xunit.html#checkingTheErrorReport
(if you scroll down a little, you'll find an HTML-formatted output)

it is simple, but efficient ; the output report contains the canonical 
path of each node in fault (the canonical path is the XPath expression 
that starts from the root and descend child from child by naming it and 
setting its position regarding its parent : e.g. /root[1]/elem[5]/ <at> attr)
namespace URIs are supplied if you have any, and they don't clash even 
if some have been remapped in the documents

enjoy !

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Adrian Paschke | 2 Aug 21:15 2007
Picon

RuleML-2007 Challenge - Extended Deadlines, 7th/17th August


          [Apologies for multiple postings]

        -- Extended Deadlines: August 7th/17th --

        RuleML-2007 Challenge: Rule Technology Showcase

            October, 25th, 2007 - Orlando, Florida

      http://2007.ruleml.org/index-Dateien/Page787.htm

With its unique emphasis on the practical use of rule technologies in
distributed Web-based environments, RuleML-2007 will feature a Challenge
with a focus on rule applications and rule-based tools. The challenge
offers participants a unique possibility to demonstrate their commercial
or open source tools, use cases, and applications.

Those demo paper submissions that are received by August 7th, and
accepted, will participate in the Challenge and be published in the
Springer LNCS Proceedings.
Those that are received a little later, but by August 17th very latest,
and accepted, will participate in the Challenge and may be considered
for publication in the Proceedings.

Submissions of demo papers (3-5 pages) for the RuleML-2007 Challenge can

be sent to

ruleml2007 AT easychair.org.

The RuleML-2007 Challenge is being held as part of the International
RuleML Symposium on Rule Interchange and Applications (RuleML-2007:
http://2007.ruleml.org/) - to be held in Orlando, Florida, on 25th/26th
October, in co-location with the 10th Business Rules Forum.

For more information please visit:
http://2007.ruleml.org/index-Dateien/Page787.htm

Sincerely Yours,

Challenge Co-Chairs

Alexander Kozlenkov, Betfair Ltd., London, UK
alex.kozlenkov AT betfair.com

Ralph Hodgson, TopQuadrant, Inc., Mountain View, USA
rhodgson AT topquadrant.com

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Costello, Roger L. | 2 Aug 22:18 2007
Picon

A single, all-encompassing data validation language - good or bad for the marketplace?

Hi Folks,

The XML Schema working group is in the process of incorporating rules
(assertions) into the XML Schema language:

      "... one of the things we had to decide when putting 
       XPath-based assertions into Schema 1.1" [Noah Mendelsohn]

Thus, the XML Schema language will become both a grammar-based language
as well as a rule-based language.

Up till this date, grammar-based and rule-based languages have been
kept separate:

    Grammar-based Languages: XML Schema, Relax NG, DTD

    Rule-based Languages: Schematron, RuleML

What do you think about XML Schema working group incorporating
rule-based capabilities into the language?

Here are some potential advantages and disadvantages:

ADVANTAGES

1. Need only one language to express all data validation requirements.

2. Possible performance improvement (as compared to separate languages
with separate validations).

DISADVANTAGES

1. XML Schemas is already quite large and complex.  This will make it
larger and more complex.

2. Discourages the use of a pipeline of validations for implementing
data validation requirements.

3. Possible performance degradation since, for example, validation
can't be halted when grammar requirements fail.

4. Replacing one grammar language with another becomes prohibitive
(example: you may want to replace XML Schemas with Relax NG)

5. Discourages competition.  Today there is a competition among the
schema languages.  A single language that does everything may reduce
the competition.

QUESTIONS

1. Can you add to the above list?  What other advantages and
disadvantages are there?

2. Is grammar validation of a fundamentally different nature than rule
validation?

3. If so, is it reasonable to merge two fundamentally different things?

4. Is it in the best interest of the marketplace to have a single,
all-encompassing data validation language, or is it better to have
multiple data validation languages that work together?

/Roger 

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Michael Kay | 2 Aug 22:37 2007

RE: A single, all-encompassing data validation language - good or bad for the marketplace?

> 5. Discourages competition.  Today there is a competition 
> among the schema languages.  A single language that does 
> everything may reduce the competition.

You're suggesting it's a bad idea to put this feature in XML Schema because
it will encourage more people to use XML Schema? Well, there's a certain
twisted logic in that, I suppose. But it's not the kind of argument that's
going to stop the development!

Assertions in schema are great. I've got a prototype implementation in Saxon
and have been playing with it, it's very powerful, especially as you can use
doc() to access external documents, you can call Java extension functions,
and so on. My only complaint is the spec doesn't go far enough, for example
assertions are defined on complex types but not on simple types.

Michael Kay
http://www.saxonica.com/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

noah_mendelsohn | 2 Aug 23:05 2007
Picon

Re: A single, all-encompassing data validation language - good or bad for the marketplace?

Whoa.  First a caveat, I'm speaking very much for myself here, not for the 
Schema WG. 

While I think the questions you're asking here are interesting, I think 
you are somewhat mischaracterizing the goals of the assertions work 
proposed for Schema 1.1.   You seem to be implying that the goal is to 
replace rule-based languages like Schematron, or to discourage the use of 
pipelines.  That's not how I see it.  I think everyone involved agrees 
that there are many important and useful "rules" that you either won't be 
able to express in Schema 1.1, or at least that you won't be able to 
express as conveniently and naturally as you can in, say, Schematron.

So what are the new assertions in W3C XML Schema (XSD) version 1.1 trying 
to do?  XSD is a type-based language.  You can declare two elements to be 
integers, and you then know that the constraints on their contents are the 
same.  Similarly you can declare complex types, which allow for element 
and attribute children, and there too, any two elements with the same type 
have the same content contstraints.  So:

        <element name="width" type="measurement"/>
        <element name="height" type="measurement"/>

tells you that the content rules for <width> elements and <height> 
elements are the same, regardless of where those elements appear.  This 
gives a very natural bindng to program structures and databases;  in a 
language like Java you can map the type "measurement" to a class, and each 
instance of a <width> or <height> element maps to an instance of that 
class.  Those are then likely to be assignment compatible.  If in your 
Java code you want to say "tableWidth = roomWidth" it probably works. 
XQuery leverages the fact that types have this clean, 
context-indepedendent semantic.

In Schema 1.0, most of the constraints you could express for a complexType 
were in the former of a grammar for the child element, and occurrence 
rules for attributes.  In schema 1.1, we add additionally the ability to 
apply XPath predicates >to the subtree governed by the type<.  That's 
architecturally appropriate for Schema (IMO), but much more limited than 
what Schematron allows.  The XPath constraints are thus integrated with 
the type system, and they preserve the architectural invariant that two 
instances of the same type are governed by the same constraints.  There's 
(intentionally) no way to say "a meausrement must obey these rules, unless 
the element in question has as its 3rd left sibling an element named 
<tangerine>" .  What you can do is require that all measurements be in a 
certain range, that the integer value of a measurement be less than an 
 <at> maxval attribute, etc.  Types remain context independent (I'll ignore XSD 
identity constraints, which I've always thought were a mistake precisely 
because they are not integrated with the type system.  Anyway...) 

Furthermore, because it's integrated with type-based validity checking, 
assertion failures in Schema 1.1 are integrated with the reporting of 
other validity failures.  I believe this is important and useful, 
particular in the cases where validity checking is invoked through an API 
by some container application (as opposed to being invoked interactively 
by a user reading error messages on a screen.)

All this represents a tradeoff.  It does less than what Schematron does. 
What it provides, is well integrated with the type and validity reporting 
system of the language.  We believe that this facility will allow users to 
check many of the constraints they have been asking to enforce, but have 
been unable to do in Schema 1.0.  It will be particularly appropriate when 
those constraints seem naturally associated with what we call a type. 

That said, rule-based languages like Schematron have shown value for 
expressing constraints that are much more ad hoc, or at least that involve 
markup that is scattered relatively widely in an instance document.  While 
I'm delighted to acknowledge that Schematron was very much a source of 
inspiration for the Schema 1.1 assertions work, at least in my opinion, 
the goal was not and is not to discourage use of Schematron or similar 
systems for expressing and enforcing the more complex constraints that 
they are good at.  I do think that there will be an interesting subset of 
today's piplines in which the need for the second step will go away.  I 
think that's a good thing.  Databinding tools, etc. will likely benefit 
from having all the constraints in one place.  In many other cases, 
particularly when business rules are complex, or relate to disparate parts 
of the instance tree, I think it will be appropriate to run a pipeline of, 
say, Schema 1.1 and Schematron.  No doubt there will be some constraints 
for which either step will do.  That's already the case today:  surely you 
face tradeoffs in deciding whether to express certain occurrence 
constraints in Schema 1.0 grammars vs. Schematron constraints.

I do think you are raising some interesting points.  I too am curious to 
see how people feel about what's proposed for Schema 1.1, and how people 
expect to use XSD and Schematron in combination once Schema 1.1 is 
available.  Still, I really don't think it's appropriate to suggest that 
Schema 1.1 is intended to replace Schematron, or to discourage use of 
Schematron or pipelines for the things they will continue to do better. 
The assertions in Schema 1.1 are designed to add a constraint facility 
that's perceived as meeting many of the needs we've heard expressed by 
users of Schema 1.0, not to completely replace rule-based systems like 
Schematron. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Costello, Roger L." <costello <at> mitre.org>
08/02/2007 04:18 PM

        To:     <xml-dev <at> lists.xml.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        [xml-dev] A single, all-encompassing data 
validation language - good or bad for the marketplace?

Hi Folks,

The XML Schema working group is in the process of incorporating rules
(assertions) into the XML Schema language:

      "... one of the things we had to decide when putting 
       XPath-based assertions into Schema 1.1" [Noah Mendelsohn]

Thus, the XML Schema language will become both a grammar-based language
as well as a rule-based language.

Up till this date, grammar-based and rule-based languages have been
kept separate:

    Grammar-based Languages: XML Schema, Relax NG, DTD

    Rule-based Languages: Schematron, RuleML

What do you think about XML Schema working group incorporating
rule-based capabilities into the language?

Here are some potential advantages and disadvantages:

ADVANTAGES

1. Need only one language to express all data validation requirements.

2. Possible performance improvement (as compared to separate languages
with separate validations).

DISADVANTAGES

1. XML Schemas is already quite large and complex.  This will make it
larger and more complex.

2. Discourages the use of a pipeline of validations for implementing
data validation requirements.

3. Possible performance degradation since, for example, validation
can't be halted when grammar requirements fail.

4. Replacing one grammar language with another becomes prohibitive
(example: you may want to replace XML Schemas with Relax NG)

5. Discourages competition.  Today there is a competition among the
schema languages.  A single language that does everything may reduce
the competition.

QUESTIONS

1. Can you add to the above list?  What other advantages and
disadvantages are there?

2. Is grammar validation of a fundamentally different nature than rule
validation?

3. If so, is it reasonable to merge two fundamentally different things?

4. Is it in the best interest of the marketplace to have a single,
all-encompassing data validation language, or is it better to have
multiple data validation languages that work together?

/Roger 

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Jirka Kosek | 2 Aug 23:41 2007
Picon

Re: A single, all-encompassing data validation language - good or bad for the marketplace?

Costello, Roger L. wrote:

> Up till this date, grammar-based and rule-based languages have been
> kept separate:
> 
>     Grammar-based Languages: XML Schema, Relax NG, DTD
> 
>     Rule-based Languages: Schematron, RuleML

Not completely. For more then year you can use NVDL to validate document
against both grammar and rule-based schemas at the same time.

Anyway, I'm glad to see xs:assertion in WXS. I have only two concerns:

- xs:assert uses probably too restricted subset of XPath

- Will be WXS 1.1 widely deployed in foreseeable future given the
investments spent by big companies on WXS 1.0 infrastructure?

			Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka <at> kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------


Gmane