[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: ID/IDREF is evil

  • From: "Len Bullard" <cbullard@hiwaay.net>
  • To: "'Michael Kay'" <mike@saxonica.com>, "'Costello, Roger L.'" <costello@m...>
  • Date: Mon, 3 Feb 2014 21:25:39 -0600

RE:  ID/IDREF is evil
Or a style language that does and a tool that implements it.

I consider id/idref one of the handier bits.  It's been around long enough
that most tools get the point and those that don't have to provide a means
to do what id/idref does easily: declare practice-reliable namelinks, 

metadata tag dependent, So local lingua but as a general practice for
grinding out hot lists, just fine.

Same concept everywhere you find it so not as belabored as the gosh darn
more compy-scifi fun of meta-declared/derived links.

ID/IDREF:  Not broken.

len

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Monday, February 03, 2014 5:33 PM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re:  ID/IDREF is evil

I think most people would classify the ID/IDREF constraint as
extra-grammatical, rather than saying that it makes the grammar context
sensitive.

I can think of plenty of reasons not to use ID/IDREF without that one. #1
being that you need one of those ghastly DTDs.

Michael Kay
Saxonica


On 3 Feb 2014, at 22:05, Costello, Roger L. <costello@mitre.org> wrote:

> Hi Folks,
> 
> In this message I will attempt to persuade you:
> 
> 1. Do not use the ID/IDREF capability.
> 
> 2. Use a layering approach: 
> 
> 	(a) Layer 1: express your XML as a context-free grammar.
> 
> 	(b) Layer 2: express context-sensitive rules using Schematron.
> 
> 3. The ID/IDREF capability is a context-sensitive rule.
> 
> Now for my argument:
> 
> First, let me persuade you that by using ID/IDREF you have introduced
context-sensitive rules into your XML. Consider this XML, which does not use
ID/IDREF:
> 
> <Book>
>      <Title>Principles of Programming</Title>
>      <Author>M. A. Jackson</Author>
> </Book>
> 
> To show XML's rule nature, let's express it like so:
> 
> Book 	--> Title Author
> Title 	--> string
> Author 	--> string
> 
> That's a context-free grammar. 
> 
> Now let's add an ID/IDREF:
> 
> <Book seller="Amazon">
>      <Title>Principles of Programming</Title>
>      <Author>M. A. Jackson</Author>
> </Book>
> 
> Assume that @seller is of type IDREF. I don't show the corresponding ID
attribute.
> 
> Let's express that XML using grammar rules. The rule for the Book element
depends on the existence of a corresponding ID attribute; if there is none,
the Book rule is invalid. So we may express Book's rule like so:
> 
> Book Amazon --> Title Author
> 
> Read that as:
> 	
> 	In the context of an Amazon symbol 
> 	the Book element may be replaced 
> 	by Title and Author.
> 
> In other words, our grammar tells us that this a valid string 
> 
> 	Principles of Programming M. A. Jackson
> 
> only if the symbol "Amazon" exists.
> 
> See the context-sensitivity? Book is context-sensitive due to the
ID/IDREF.
> 
> Any time you use ID/IDREF in your XML document you have introduced a
context-sensitive rule into your XML document.
> 
> "So what?" you ask.
> 
> Well, here's so what:
> 	
> 	All known parsing algorithms for context-sensitive
> 	grammars are either very inefficient or very complex.
> 
> 	Reasoning about context-sensitive grammars is difficult.
> 
> 	Proofs about context-sensitive grammars is difficult.
> 
> 	Take cue from compiler developers: they separate
> 	context-sensitive processing into a separate pass.
> 
> So don't use ID/IDREF. 
> 
> Of course, that doesn't mean you will never have data that has intra-data
dependencies. What it means is that you should modularize your grammar
rules: express your context-free rules in your XML document and express your
context-sensitive rules (intra-data dependencies) in Schematron. That's a
nice, clean separation-of-concerns. That's a modular data design.
> 
> Let's recap:
> 
> 1. ID/IDREF introduces context-sensitive rules into your XML grammar
wherever there is an ID attribute and wherever there is an IDREF attribute.
> 
> 2. Don't use ID/IDREF.
> 
> 3. Modularize your rules: express context-free rules in XML and express
context-sensitive rules in Schematron.
> 
> Comments?
> 
> /Roger
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.