RE: Response to Daniel's review comments (Re: Committee Draft of ISO Schematron available)

Thanks for answering Rick. I needed these to move on with ISO
Schematron.NET.
 
>Rick say: it is the writer of the schema's job to state which language they
are using, and the writer of the implementation's job to figure out which
query languages are subsets of the ones they implement. 

Daniel says: Fair enough.

>>> "The required value attribute is a fragment of a query."
>> Don't understand this. A fragment? Why?

> Rick says: it is a fragment because we don't want to restrict it in
anyway, as might be implied by "term" or "expression" or "closure" etc.

Daniel says: Mmm... The word "fragment" gets me thinking that this may not
be a full query per the schema language. I find it missleading. If you just
say "is a query", you're not implying any limitations, IMO.

>>5.2.7 ns element
>>I still have problems understanding why doesn't schematron use the usual
>>xmlns: binding approach. I think we discussed this before, but still don't
get it  :( 

>Rick says: This is a religious area: the W3C TAG seems to take the view
that you shouldn't even use prefixes in attributes at all, which >is utterly
bogus.
>I really dislike XML Schema's approach in this regarded (
elementDefaultForm
>etc)

Daniel says: Well, besides the elementDefaultForm et all, the XSD approach
at least doesn't introduce another way of mapping prefixes to namespaces. It
uses the same one in XML-Namespaces spec. I can clearly see that for some
implementations it may be easier to have the ns element, but I think
introducing another mechanism, when a suitable one already exists is not too
good... I mean, what's so bad about the following:

<schema xmlns="http://www.ascc.net/xml/schematron"
        xmlns:po="urn:purchase-orders">
  ...
    <rule context="po:order">
     ...

I can't really tell what's the benefit of having it with the ns element:

<schema xmlns="http://www.ascc.net/xml/schematron">
  <ns prefix="po" uri="urn:purchase-orders">
  ...
    <rule context="po:order">
     ...

One benefit for Visual Studio .NET developers is that the XML editor offers
intellisense for the xmlns attribute by showing all the namespaces it "knows
about" (schemas deployed to a specific folder), as well as for
elements/attributes in the document. 
A more important concern is when you mix XHTML in here. In this case, it's
not clear (or at least confusing) for the schema developer whether he should
use <ns> or xmlns to map a prefix to the XHTML for use in the document. I
believe it's the later, but then, he will have to use one mapping for
document element/attributes and another mapping for query expressions that
may use them. Not too good, at all.
I.e.:

<schema xmlns="http://www.ascc.net/xml/schematron"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <ns prefix="xhtml" uri="http://www.w3.org/1999/xhtml">
  ...
    <assert test="xhtml:body[@style]">
      <xhtml:h1>You should use the class attribute to style the
body</xhtml:h1>

I see this as an inconvenience, at least.

> Annex A: RelaxNG Schema

Daniel says: My inexperience with RelaxNG showed up in these comments. After
using it for some days now, I feel comfortable with it and understand what
the spec specifies with it. Thanks for clarifying.

>>So, each localized version of the diagnostic element must have a different
ID, right? 
>>I guess it would be better to allow them to all have the same ID 
>>(provided they have different xml:lang attribute), so only one ID must be
referenced.

>Rick says: that definitely has attractive points, but I would prefer to
stick to something that can be validated using IDREFS. 

Daniel says: Interesting. I think a schematron implementation can validate
schematron schemas with a schematron schema too, so this kind of restriction
can be easily checked, instead of relying on IDREFS. In fairly big schemas,
I think it will be very inconvenient to modify all asserts just to include a
new language. You already have constraints that can't be expressed with
RelaxNG and are added as a normative Schematron schema. This could be part
of it. But now the question is: how on earth do you split a string with
XPath/XSLT alone? :S ... Too bad... only EXSLT can do so easily :(. 
I guess there's no workaround for this...

>>> "A correct schema has one definition only in scope for any variable 
>>> name in any context."
>> Did I say I don't like this restriction much? ;)

>Rick says: actually, neither do I, but because we do not have
implementation experience, 
>think it is better to err on the side of caution.  (If I can convince
myself in time, 
>will try to get this changed, but I cannot guarantee it.)

Daniel says: For API-based implementations, this shouldn't be a problem
(it's not for .NET). It would be good to know from someone with XSLT
experience (maybe someone who worked with the reference implementation) if
this is a problem for it. If it's not, it may be changed confidently.

>>5.3.5 flag attribute
>Can't understand what this attribute is about  :( 

>Rick says: see posting yesterday

Daniel says: I'm still digesting it ;)




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com