Jirka
Re: Maybe someone who was on SC34 at the time when whole
DSDL was designed could explain what the intention of Part 6 is.
The original definition of the role of Part 6 as defined back in 2003 were:
Path-based integrity constraints allow path-based languages, such as XML
Path, to be used to identify relationships
between elements that must, or may not, occur in valid documents.
This Part is based on the four-directional tree path navigation paradigm
(parent, child, preceding sibling and following
sibling) defined in XML Path. It allows:
- the identification of paths that must exist in the document if a
particular element, attribute or subtree exists within
the document
- the expression of identity and integrity constraints on components of
document instances identified through the
use of path expressions.
This definition was accompanied by the following questions:
What else should path-based integrity constraints provide us with? What do
these integrity constraints do that cannot
be done using paths defined within Part 3?
Paths are used in both Parts 3 and 6. Should paths be described in a
separate part referenced by the others? Is the
normative reference to XML Paths within Part 0 sufficient? Could other forms
of path specification be required at a
future date?
By 2006 this had been refined to:
Path-based integrity constraints allow path-based languages, such as the XML
Path Language (W3C XPath), to be
used to identify relationships between elements that must, or may not, occur
in valid documents.
Part 6 of ISO/IEC 19757 is based on the four-directional tree path
navigation paradigm (parent, child, preceding sibling
and following sibling) defined in W3C XPath.
Path-based constraints can be used to identify a fragment of a document
against which a specific schema may be
applied. For example, if a document has adopted the CALS table model without
assigning a specific namespace to
CALS-conformant elements, this part can be used to select a table and parse
it according a schema fragment that
defines the structure of CALS tables.
Path-based constraints also permits the specification of inter-document
relationships, allowing the validity of one
document to depend on the presence of specific information in another
document.
During discussions in 2006 it was decided that the role of Part 6 should be
changed to be one that provided stream-based processing of XML files, but no
user constraints were defined. Instead it was proposed that STX was a
possible starting point to meet the requirements. Now we need to justify
this change, and revise the requirements for Part 6 to cover the use cases
that Rick and others envisaged for STX. Hence my call to all members of this
discussion list to submit possible reasons for moving from path based
constraints to a stream-based processing paradigm.
Martin
----- Original Message -----
From: "Jirka Kosek" <jirka@kosek.cz>
To: <dsdl-discuss@dsdl.org>
Sent: Friday, August 17, 2007 1:10 PM
Subject: [dsdl-discuss] Re: Result of the ballot
Petr Cimprich wrote:
> This is of course much better than an ad-hoc extension. I'm starting to
> like the idea that Part 6 could be an STXPath binding for Schematron.
> Who and how can decide whether this is a way to go?
I think that the biggest problem of Part 6 is a lack of requirements. I
was unable to find requirements which should be satisfied by Part 6.
Without knowing requirements it is hard to judge whether some existing
technology could implement them.
Is Part 6 supposed to provide mechanism similar to xs:key/xs:keyref?
Should it be more ambitious and provide means for checking whether
references inside document are acyclic/cyclic/...?
Should it be possible to define constraints against more then one document?
> In the matter of use cases, I see them as very important too. A
> buffering mechanism should be designed according to use cases we want to
> cover by this tool. Does anyone have some practical use cases in mind?
I can provide several use cases but I would like to know intended scope
of Part 6 before. Maybe someone who was on SC34 at the time when whole
DSDL was designed could explain what the intention of Part 6 is.
Jirka
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Fri Aug 17 22:58:45 2007
This archive was generated by hypermail 2.1.8 : Thu Aug 23 2007 - 11:03:04 UTC