Epic states my document is invalid, when it"s not

[ChristopheLefeb]

Hi Adepters,

I have a strange behaviour with Epic 4.3.

With this DTD :

It does consider that <doc><intro>stuff</intro></doc> is not valide.

/doc [A11155] final tag encountered. More content is required (approximative translation)

I do not encounter trouble with <doc></doc>.

Somehow the presence of <intro> makes Epic unable to consider that one branch of the | can be empty.

Thanks for any insight

Christophe Lefebvre

LexisNexis France

[LynnHales]

I am posting this to kind of duplicate what I sent Christophe when I (AGAIN)
forgot to reply to adepters and not to the sender directly.

There is not a problem with Epic. The parser is reporting in your case that
the required element is missing. If your document were like this:

<doc>
<intro>Stuff</intro>
Some optional stuff
</doc>



There would be no problem. Epic also does not report just the root element
alone as incomplete, it really has not begun.



Lynn

[ChristopheLefeb]

I fail to understand how the absence of (which is optional) would make mandatory.
In my understanding the content model (a+ | b*) should allow the fact that there is nothing.

Plus, when I parse the document with another parser (Omnimark in this case) the document is considered valid.

Christophe Lefebvre
LexisNexis France

------
De: Lynn Hales [

I am posting this to kind of duplicate what I sent Christophe when I (AGAIN) forgot to reply to adepters and not to the sender directly.

There is not a problem with Epic. The parser is reporting in your case that the required element is missing. If your document were like this:

<doc>
<intro>Stuff</intro>
Some optional stuff
</doc>

There would be no problem. Epic also does not report just the root element alone as incomplete, it really has not begun.

Lynn

[DavidS.Taylor]

Hi Christophe,

Re-stating what Lynn said...

Your example has neither or in <intro>.

The error message is complaining that is missing, it isn't optional (+ = repeatable element that _must_ occur at least once).

David

David S. Taylor

Project Manager, Production and Marketing
Building Regulations | NRC Construction
National Research Council Canada
Building M-23A, Room 114 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
Telephone: +...

[DavidS.Taylor]

Sorry,

That should have said 'Your example has neither or _following_ <intro>.'

David

[ChristopheLefeb]

It may sound a bit rhetorical, but from my point of view <intro> is followed by with an occurrence of 0.

Now, I guess I will take the easy course and change the content model to


But I really would like to understand what is going on here.

Christophe Lefebvre
LexisNexis France

-----Message d'origine-----
De: Taylor, David S. [

Sorry,

That should have said 'Your example has neither or _following_ <intro>.'

David

[RichardSteadman]

Hi,

The SP parser also confirms that the document should be valid,
accepting blank content as an instance of "b*".

However, it's probably better to change the content model to
something less confusing

Regards,
Richard


At 10:00 AM 26/09/2014, Lefebvre, Christophe (LNG-PAR) wrote:
>It may sound a bit rhetorical, but from my point of view <intro> is followed by with an occurrence of 0.
>
>Now, I guess I will take the easy course and change the content model to
>
>
>But I really would like to understand what is going on here.
>
>Christophe Lefebvre
>LexisNexis France
>
>-----Message d'origine-----
>De : Taylor, David S. [
>
>Sorry,
>
>That should have said 'Your example has neither or _following_ <intro>.'
>
>David
>
>

[ClayHelberg]

I agree with Christophe, I don't see why the parser would have a problem here (and apparently other parsers don't have a problem).

The (a+|b*) should be satisfied by empty content, which would be the second alternate (b) with zero occurrences.

(Granted, this is an awkward construction, and I probably would have specified it differently if I were writing the DTD. But I still have trouble seeing why the old Epic parser would interpret this in the way it seems to be doing.)

Also, the way I read the declaration, I can't see any reason why it should matter whether the optional <intro> exists in the structure as far as how the (a+|b*) alternative is interpreted. If <doc></doc> is valid (as Christophe reports to be the case), then <doc><intro>foo</intro></doc> should also be valid, as far as I can see.

--Clay

[LynnHales]

One day I will learn. 😞

Lynn

[LynnHales]

I can see why the parser would fail in the case of the
<doc><intro>stuff</intro></doc>

How does the parser know if the optional really isn't there? I have a
choice of one required or one optional element. Very awkward to say the
least. I really cannot think of a good way to define this either. I don't
think I've seen anything like this in my 20 plus years of doing DTDs (and
the DOD can come up with some really WEIRD models).

As to Epic not making just <doc></doc> invalid, it has always seemed to have
allowed just a root element to be saved as valid.


Lynn

[GarethOakes]

This is probably a question best answered at an SGML list or possibly
xml-dev?

I think I agree with Lynn here. I'm no SGML expert, and XML is only
loosely related, but my interpretation of the W3C XML specification is
that this would be the correct way to represent the required construct:




Leaving out the question mark means that something from the (a+|b*) is
required before </doc>.

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co