Rick
[I'm posting this on behalf on Martin, who can't access this list while
in Oslo]
At today's WG1 meeting we discussed your suggestions for adding
properties to Schematron.
You raised the following open questions:
1. Should this be in the Schematron namespace, or is it a general enough
feature that other parts of DSDL can use it? I.e. is this a new annex,
a new content model, a TR or a new part? I think it might be neater to
contain it to just Schematron, and any other editor who wanted it can
clone it into their namespace.
We agree that it would be neater to constrain it to just Schematron.
2. Is this (schematron+property+some conventions) powerful enough to be
used as DSDL part 6 Path-based integrity constraints? I suspect not.
We have come to the conclusion that if we could combine Schematron with
XPath 2.0 we would probably not need to have a Part 6 as this together
with the XProc language looks as if they may suffice to meet most of the
proposed use cases for Part 6.
At the last WG1 meeting you offered to "contact the STX (Streaming
Transformations for XML) developers to determine if they would be
willing to submit their work for standardization as Part 6 of DSDL." Did
you get any response from them? Mohamed Zergaoui, who joined us for the
first time this week, also proposed this as a possibility, suggesting we
add Streaming in front of the current name. He is in contact with the
STX developers through his work at W3C and will try to suggest the
possibility as well.
We would like to suggest that a revised version of Part 3 be prepared to
include the additional properties that you are suggesting together with
a switch to using XPath 2.0 locations. If this idea is acceptable to
you, how soon would you be prepared to start work on this? (I need to
ensure that the necessary NWI is prepared, which should be submitted
with a CD draft that outlines where the changes would need to be made.
Martin Bryan
WG1 Convenor
> -----Original Message-----
> From: dsdl-discuss-bounce@dsdl.org
> [mailto:dsdl-discuss-bounce@dsdl.org] On Behalf Of Rick Jelliffe
> Sent: 06 January 2007 01:53
> To: dsdl-discuss@dsdl.org
> Cc: schematron-love-in@eccnet.com
> Subject: [dsdl-discuss] Suggestion for adding properties to Schematron
>
> I think there would be good value in adding a property
> element to Schematron (and perhaps to have it available in
> all DSDL parts.)
>
> <pattern ...>
> <rule context="name">
> <property name="sch:type" value="xs:NMTOKEN" />
> <assert test=" ... ">
> ...
>
> So a rule could have zero or more property elements. The
> property elements would be basically name/value pairs. The
> properties would be properties of the concat(
> parent::sch:rule/@context, parent::sch:rule/@subject) node(s).
>
> Such a mechanism would increase the declarative power of
> Schematron, in particular to allow
>
> * Connection to DTTL and XSD types. XForms does this
> already, so it is a proven system.
>
> * A better way to include integrity constraints (we took out
> sch:key and made it xslt:key because it introduced an
> implementation dependency, but I was never really happy with it
>
> * A way to allow more business rules and declarative
> information, and to allow smarter interfaces. I am also
> interested in systems that convert from grammars to
> Schematron, and I think it would be good to be able to
> round-trip more information in the Schematron schema, such as
> keeping the initial content model.
>
> * A potential way to tie to data models (e.g. an ER diagram) better.
>
> My motivating need for this is a collaborative business rules
> development system (web based) that a client is discussing.
> It would be really useful to have these kinds of properties,
> because they want to be able to add more metadata.
>
> An abstract rule could be made which just contained
> properties, allowing them to be bundled and named.
>
> What about contention? I.e. where a node is assigned a
> property from one pattern and then a contradictory property
> or value from another patterns?
> I would overcome this merely by saying that the property is
> not a property of the node itself, but a property of the node
> in a particular pattern and a particular rule. So a property
> instance is a quintet
> [ name, value, node, pattern, rule]
> and it is up to the application to sort out the difference.
> (At the simplest, people can just put all their type
> properties into a single
> pattern.)
>
> Should there be a facet style mechanism, for parameters and facets?
> <property name="sch:type" value="xs:NMTOKEN">
> <facet name="maxLength" value="23" />
> ...
> </property>
> If so, what should it be called? facet? arg? param?
>
> This still avoids class-based modeling, because while one
> abstract rule can include another, there is no sub/superclass
> relation between the abstract rules (they are "mix-in"
> inheritance, if you like.)
>
> Open Questions w.r.t. ISO DSDL
> -------------------------------
>
> Should this be in the Schematron namespace, or is it a
> general enough feature that other parts of DSDL can use it?
> I.e. is this a new annex, a new content model, a TR or a new
> part? I think it might be neater to contain it to just
> Schematron, and any other editor who wanted it can clone it
> into their namespace.
>
> Is this (schematron+property+some conventions) powerful
> enough to be used as DSDL part 6 Path-based integrity
> constraints? I suspect not.
>
>
> Feedback welcome
> Rick Jelliffe
>
> --
> 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)
>
>
-- 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 Mar 23 16:45:14 2007
This archive was generated by hypermail 2.1.8 : Tue Mar 27 2007 - 07:23:03 UTC