OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a or b or both - mystery..




The question and answer are correct.
I think we should all know this. I am presenting a set of facts --
In my opinion, there are two solutions for solving the schemas issues --
(1) Use deterministic content models such as DTD or XML Schemas
(2) Use non-deterministic content models as in RELAX or TREX.

Tentatively, deterministic content models are easier for specifying key
constraints, but I think document processing (such as XSLT or Query) gets
*very* ugly.

Non-deterministic content models are very clean for document processing,
but we have to do *small* (note the emphasis on small) tricks to support
key constraints -- I think I can say that RELAX group has people who very
actively work on this.

Also, if you look at TREX's goal, it says non-deterministic content
models are almost necessary and definitely convenient for several use
cases.

I should say this -- I believe *very* strongly in non-deterministic
content models, and I think that is the way document processing can be
supported neatly. So I am *very* biased, and I use RELAX for my purposes -
and not XML Schema. Actually I think I cannot afford to use XML Schema.

If you want to know more about deterministic content models, you should
read Appendix E of XML 1.0, it is very good. Also, I think I am right when
I say that Anne Bruggemann Klein is the first person to analyze these
deterministic content models as in DTDs, but she also opines that
deterministic content models are *very* restrictive and is not the way it
should be.

I also heard this: XML Schema WG has discussed deterministic content
models a lot, and they decided to use deterministic content models largely
for parser simplicity -- which I think is a non-valid reason at this
point. In short, I do not know why XML Schema:Structures is becoming a
standard in the first place.

<warning>speaking for himself only</warning>

regards - murali.

On Tue, 17 Apr 2001, Marcus Carr wrote:

>
> Anshul.Mittal@iint.com wrote:
>
> > I have a requirement where I have to specify the following condition
> in a dtd... > > ecat-supp-name and ecat-supp-code are individually
> optional but one of the > two needs to be present to locate the vendor
> > > So I need to have ecat-supp-name or ecat-supp-code or or both in
> the higher > level element... > > Thats how I wrote the dtd . > >

> <!ELEMENT LineItem
> (((EcatSuppName|EcatSuppCode)|(EcatSuppName,EcatSuppCode)),
> ((EcatSuppPartNbr|EcatSuppModel)|(EcatSuppPartNbr,EcatSuppModel)),
> ManufacturerName?, EcatItemDesc, CommCodeXref?, EcatQuantity,
> EcatUom, EcatUnitPriceFx, EcatCurrency, EcatCatalogId?,
> EcatPONumber?) But getting the following error " Content Model is
> non - deterministic for LineItem" when I try to validate this dtd.
>
> The problem is that the processor can't determine where it is when it
> encounters the EcatSuppName element, because it doesn't know if it
> requires an EcatSuppCode to follow or not. Even if you got past this
> problem for this set of elements, it would recur when the processor
> got to the EcatSuppPartNbr in the same content model. The following
> model allows either or both elements in the set to occur and requires
> one as the minimum. The only restriction is that if both elements in
> the set exist, they must be in a fixed order, but that restriction is
> present in your current model anyway.
>
> <!ELEMENT LineItem    (((EcatSuppName, EcatSuppCode?) | (EcatSuppCode)),
>                        ((EcatSuppPartNbr, EcatSuppModel?) | (EcatSuppModel)),
>                        ManufacturerName?, EcatItemDesc, CommCodeXref?,
>                        EcatQuantity, EcatUom, EcatUnitPriceFx, EcatCurrency,
>                        EcatCatalogId?, EcatPONumber?)>
>
> > Any Idias ??
>
> Extending Easter holidays for another week? :-)
>
>
> --
> Regards,
>
> Marcus Carr                      email:  mrc@allette.com.au
> ___________________________________________________________________
> Allette Systems (Australia)      www:    http://www.allette.com.au
> ___________________________________________________________________
> "Everything should be made as simple as possible, but not simpler."
>        - Einstein
>
>
>
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org
>