is this is?

Earn a big decrease on your Meds-RX
Major classes, Highest quality.
immeasurable disversification, including Hard to find drugs
No prescriptoin recommeneded.
Private with No waiting rooms or date vital
take in compass and Save! when extra

http://www.dyhq.gettingdonefire.org/cb/

I nest will not harm you
hem. It was Lys, and she was alive and so far counter 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

RE: logic error in iso draft?

    Hmm. I am not sure, but I do take your point the fact that 
    no contexts were matched may be of interest to users 
    sometimes, especially when flying solo.

    I would be very reluctant to call this "invalid" because 
    Schematron is positioned to work as an ancilliary to 
    grammar-based schema languages (DTD, RELAX, XS, etc.): so 
    it is quite possible that a document may not have elements 
    that the Schematron schema covers.

Rather than invalid, how about a very clear warning that this could
happen (under such and such a circumstance), then quote
<pattern id="roots">
  <title>Allowed Roots</title>
  <rule context="/*">
    <assert test="/a or /b or /c or /d">
       Only the following elements are allowed at the top-level: a, b, c, d
    </assert>
  </rule>
</pattern>

as the way to catch it
(though your example of a mistyped ns wouldn't be caught)

regards DaveP

--

-- 
DISCLAIMER: 

NOTICE: The information contained in this email and any attachments is 

logic error in iso draft?

Something that cropped up in testing... I used a random xml document and 
a minimal schema and it was reported as valid. Oops.

The reason was that no assertions failed, because no rules fired (which 
was correct for this schema/instance combination), so there were no 
failed assertions, but no /passed/ assertions either. I checked the 
draft to see if I'd made a mistake with the semantics, and I can't see 
it. Should sec 3.4 should be changed from reading:

"An instance document is valid if no assertion tests in fired rules of 
active patterns fail."
to
"An instance document is valid if no assertion tests in fired rules of 
active patterns fail and at least one rule fires." ?

I can see there might be edge cases where matching 'anything' makes 
sense, but is this really what we mean by a valid document? Or a 'good' 
schema, for that matter - since a well-written schema would have picked 
up that this document wasn't an instance anyway, should a 'good' schema 
also assert that "for all instance, schema, active-phase combinations, 
there exists a subject, pattern and rule, (the subject being a member of 
that instance, the pattern being a member of that schema, the pattern 
being a member of that active-phase, the rule being a member of that 
pattern), for which the subject matches the rule.". Along with the 
schema restrictions that imply a simplified rule contains at least one 
assert or report, this would be enough to ensure that one assertion 
would be tested by the schema for all instances and active phases.

So: should I report no assertions being tested for an instance as a 
valid document, an invalid document, or an error?

What are some examples of large-scale Schematron installations?

How many documents processed per some period of time?

How many document types?

How many rules were required?

How long did it take to build?

Or, if those are the wrong metrics to figure out how
Schematron scales, what are the right ones?

	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: Abstract Pattern Processing Model

(I know this was 3 weeks back but no-one replied to Dan, and its quiet 
in here)

Daniel wrote:
 > It"s not clear from the specification how should the abstract pattern be
 > processed. Specifically, given that a node can only be evaluated by 
one rule
 > inside a pattern, the processing order matters. Therefore, if a patterns
 > specifies is-a pointing to an abstract pattern that contains further 
rules,
 > which ones should be processed first?

This can't happen - the RelaxNG schema contains the restriction that 
parameterized patterns (pattern[ <at> is-a]) cannot contain rules

 > Is there a way to make the following more explicit in 6.2 Simplified
 > Syntax?:
 > "- Resolve all abstract patterns by replacing parameter references with
 > actual parameter values"
 >
 > I think the simplified syntax for this should be the direct inclusion 
of all
 > rules in the abstract pattern at the beginning of the inheriting pattern
 > declaration, and considering all parameter references as if they were 
<let>
 > elements. This is because the syntax for parameter and variable 
references
 > in most languages is the same.

The syntax may be the similar, but the intent is different. I think this 

Conformance testing, SVRL

I'm starting to think about how to test my impl for conformance. I've 
looked at SVRL and it seems a step or two short of actually doing an 
output comparison with a reference implementation (which seems like the 
obvious approach). Has anyone else tackled this? Here's what I was thinking:

- run impl1, impl2 with test schema and input, generating svrl1, svrl2
- run a 'conformance' stylesheet (see below) against svrl1 to generate a 
schematron schema check1
- validate svrl2 with check1
- run the 'conformance' stylesheet against svrl2 to generate a 
schematron schema check2
- validate svrl1 with check2

the assertions generated by the conformance stylesheet would test for 
existence of leaf elements, checking all ancestor-or-self element 
names/attributes eg given:
<a x='1'>
    <b y='2'>
       <c/>
    </b>
    <b y='2'>
       <c/>
    </b>
</a>

... we generate one test for existence of "/a[ <at> x='1']/b[ <at> y='2']/c". By 
generating tests from both svrl1 and svrl2, we can test for missing 
items in svrl2, and extra items in svrl2 (since they are 'missing' in 
svrl1). My thinking behind doing tests like this rather than some kind 
of 'diff' is that the order of pattern use is undefined, and that 

ISO draft typos

I've spotted a few typos in the draft I don't think Daniel picked up on:

5.2.9, 5.2.10, Annex A; there is some confusion in the spec between 
'name' and 'id'. pattern, phase have a 'required name attribute' 
according to the text, but the RelaxNG schema has 'id'.

5.2.10,  'the name given in in the phase attribute on the schema' should 
read 'the name given in in the defaultPhase attribute on the schema'

5.2.5 ' The required value attribute is an expression evaluated in the 
current context that returns a string' vs 6.4 ' The let value query 
language, a function which returns a data value.' (missing the words 
'coercable to a string' that appears on previous lines)  - which? I 
don't see the need to restrict the values returned by let queries to 
strings, if the query language supports their use. (Dan picked up on the 
first line too, but he didn't mention that its inconsistent with later 
bits of the spec)

Some other bits that need clarified:

5.2.4 'an external XML document with a schema fragment'. If this 
external document is to be loaded by an XML parser, it needs to be 
well-formed; so it'll have a root element. What would that be? Should it 
just be 'something' in another namespace that we can ignore as its 
children are the things that are important? Or would the external 
documents consist of e.g. a single <rule> element, so the root isn't 
ignorable? (should I be looking

5.2.6 'an expression evaluated in the current context that returns 
either a string that is the name of a node or a node that has a name' - 

Re: Response to Daniel's review comments (Re: [Schematron-love-in] Committee Draft of ISO Schematron available)

Daniel Cazzulino wrote:

>>>>"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.
>
>  
>
Well, it may not be a full query: the intent is not to constrain how it 
is chunked in any way.
In particular, if the query language is not composable then it would be 
incorrect to call
a part of a query "a query".

>>>5.2.7 ns element
>>>

Extends element

Abstract pattern processing model

RelaxNG schema omision of the flag attribute