dtds, customization question

Discussion in 'XML' started by Jeff Kish, Jan 17, 2007.

  1. Jeff Kish

    Jeff Kish Guest

    It's been a while since I had to delve into this topic, and I hope this is a
    good place for this question.

    I don't know much about schemas, probably a bit more about dtd's.
    I have a system that people/users can customize extensively.
    I'm thinking that if they could use xml to transfer information between
    systems, that would be helpful.

    So I figured that I would need to define a dtd.
    But someone told me a dtd would be too limiting as customers need to be able
    to support exporting/importing extra tables/columns etc that were not
    originally specified.

    So is a dtd really limiting in this respect, or could I define elements to
    handle that, such as generic table and column names and values?

    Is a schema any more advantageous?


    Thanks for your time. I'll post elsewhere if this isn't a good place for
    this.. just flame me.


    Jeff Kish
     
    Jeff Kish, Jan 17, 2007
    #1
    1. Advertising

  2. Lax schemas can be written, which leave the content unconstrained
    (except for well-formedness) in specific places. That's part of how you
    design something like XHTML which will have elements from other schemas
    mixed into it.

    DTDs do something similar using the ANY keyword.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Jan 17, 2007
    #2
    1. Advertising

  3. Jeff Kish

    Peter Flynn Guest

    Jeff Kish wrote:
    > It's been a while since I had to delve into this topic, and I hope this is a
    > good place for this question.


    Good as any.

    > I don't know much about schemas, probably a bit more about dtd's.
    > I have a system that people/users can customize extensively.
    > I'm thinking that if they could use xml to transfer information between
    > systems, that would be helpful.


    So far, so good...

    > So I figured that I would need to define a dtd.
    > But someone told me a dtd would be too limiting as customers need to be able
    > to support exporting/importing extra tables/columns etc that were not
    > originally specified.


    This is jumping several guns at a time.
    I assume from what you say that part of the document type will involve
    tables of some kind, right?
    Is that all numeric, or will the documents also contain text?
    Importing and exporting *what* into and out of *what*? A database? Or
    some other application like a wordprocessor or spreadsheet?

    > So is a dtd really limiting in this respect, or could I define elements to
    > handle that, such as generic table and column names and values?


    There is no inbuilt restriction in a DTD or a Schema on the depth or
    width of markup, so a table can have as many rows and columns as needed,
    and no limit has to be placed on either.

    It is certainly possible to constrain a table to having x columns and y
    rows, if you needed to -- but from what you say, you don't.

    But in a generic table typically all rows and columns have the same
    element type name, eg

    <table>
    <row>
    <col></col><col></col><col></col><col></col>
    </row>
    <row>
    <col></col><col></col><col></col><col></col>
    </row>
    <row>
    <col></col><col></col><col></col><col></col>
    </row>
    </table>

    If you wanted them all to be called by different names, then you would
    indeed be constraining them to a fixed number. But normally, if you want
    a column to have a human-understandable name, you put it in an
    attribute, eg <col name="Income">. This way any user can create tables
    of any width. You can name the rows in a similar way.

    What you may be thinking of is a typical data application taken from a
    database where a "table" has an entirely different meaning. Once
    re-expressed in XML, these typically have a format like

    <quill-pen-stuff>
    <accounting-record id="abc" lots="of" other="attributes">
    <income>£20</income>
    <expenditure>£19.19s.6d</expenditure>
    <result>happiness</result>
    </accounting-record>
    <accounting-record id="xyz" lots="of" other="attributes">
    <income>£20</income>
    <expenditure>£20.0s.6d</expenditure>
    <result>misery</result>
    </accounting-record>
    </quill-pen-stuff>

    In XML terms this is not a table. It's just an element containing other
    elements containing other elements. Referring to it in XML as "a table"
    or "a record" or "a field" is inaccurate, fallacious, and misleading,
    and usually evidence of spending far longer in the company of databases
    than is healthy for a grown adult :)

    You can certainly format and view it in tabular form, no problem. But
    you can't arbitrarily add undeclared elements to its content when using
    a DTD or Schema, because that is precisely what they are intended to
    prevent happening. They act as a control on the formation of a document,
    to ensure that it happens according to plan. If there is no plan (as you
    seem to imply) then all bets are off for this structure.

    > Is a schema any more advantageous?


    Nope. It's the conceptual part, not the application :)

    Without seeing your application I can't judge what you need, but at a
    wild guess you could easily define an extensible container structure
    like the generic table above, and allow your customers to add as many
    subelements as they like provided they give each one a name in an
    attribute value (or some such constraint). Neither a DTD nor a Schema
    imposes any restrictions on this method.

    ///Peter
    --
    XML FAQ: http://xml.silmaril.ie/
     
    Peter Flynn, Jan 18, 2007
    #3
  4. Jeff Kish

    Jeff Kish Guest

    On Thu, 18 Jan 2007 00:26:13 +0000, Peter Flynn
    <> wrote:

    >Jeff Kish wrote:
    >> It's been a while since I had to delve into this topic, and I hope this is a

    <snip>
    >This is jumping several guns at a time.
    >I assume from what you say that part of the document type will involve
    >tables of some kind, right?
    >Is that all numeric, or will the documents also contain text?
    >Importing and exporting *what* into and out of *what*? A database? Or
    >some other application like a wordprocessor or spreadsheet?
    >
    >> So is a dtd really limiting in this respect, or could I define elements to
    >> handle that, such as generic table and column names and values?

    >
    >There is no inbuilt restriction in a DTD or a Schema on the depth or
    >width of markup, so a table can have as many rows and columns as needed,
    >and no limit has to be placed on either.
    >
    >It is certainly possible to constrain a table to having x columns and y
    >rows, if you needed to -- but from what you say, you don't.
    >
    >But in a generic table typically all rows and columns have the same
    >element type name, eg

    <snip>
    >
    >What you may be thinking of is a typical data application taken from a
    >database where a "table" has an entirely different meaning. Once
    >re-expressed in XML, these typically have a format like
    >
    ><quill-pen-stuff>
    > <accounting-record id="abc" lots="of" other="attributes">
    > <income>£20</income>
    > <expenditure>£19.19s.6d</expenditure>
    > <result>happiness</result>
    > </accounting-record>
    > <accounting-record id="xyz" lots="of" other="attributes">
    > <income>£20</income>
    > <expenditure>£20.0s.6d</expenditure>
    > <result>misery</result>
    > </accounting-record>
    ></quill-pen-stuff>
    >
    >In XML terms this is not a table. It's just an element containing other
    >elements containing other elements. Referring to it in XML as "a table"
    >or "a record" or "a field" is inaccurate, fallacious, and misleading,
    >and usually evidence of spending far longer in the company of databases
    >than is healthy for a grown adult :)
    >
    >You can certainly format and view it in tabular form, no problem. But
    >you can't arbitrarily add undeclared elements to its content when using
    >a DTD or Schema, because that is precisely what they are intended to
    >prevent happening. They act as a control on the formation of a document,
    >to ensure that it happens according to plan. If there is no plan (as you
    >seem to imply) then all bets are off for this structure.
    >
    >> Is a schema any more advantageous?

    >
    >Nope. It's the conceptual part, not the application :)
    >
    >Without seeing your application I can't judge what you need, but at a
    >wild guess you could easily define an extensible container structure
    >like the generic table above, and allow your customers to add as many
    >subelements as they like provided they give each one a name in an
    >attribute value (or some such constraint). Neither a DTD nor a Schema
    >imposes any restrictions on this method.
    >
    >///Peter

    thanks for the reply.

    Well, to talk about it in generic terms,
    it is a database export/import, but the export is to be supplied by a
    3rd party, and the import I think we get to write, so it is between
    two disparate databases.

    So I figured, hey XML is a good candidate.
    So I wanted to specify elements like you mentioned, with subelements
    representing table relationships.

    For example say we were talking about documentation for assets.

    Then there might be an asset table, and a document table, and a
    asset_document table that gave many to many relationships.
    Then there could be a part table and a part_document table to map what
    parts go with what document.

    Finally to get information from one db to another, I was thinking
    systemexport := asset +, document *, part * (i.e.
    one or more assets, zero or more documents, zero or more parts)
    asset := id, description, document * (i.e. zero or more documents)
    document := id, description, part+ (one or more parts)
    part := id, description

    so you could have an asset without a document,
    a document without an asset,
    a part related to neither,
    or you could develop a bill of materials for an asset using
    the information if structured as above.

    but if someone customizes their system I'd like to be able to add more
    'stuff' to the data.xml file, and was trying to figure out the dtd.

    the data columns in the table could be anything (int, string, blob
    etc)

    thanks for your thoughts.
    Jeff
     
    Jeff Kish, Jan 18, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JimO

    DTDs and syntax

    JimO, May 30, 2005, in forum: HTML
    Replies:
    3
    Views:
    443
    Jukka K. Korpela
    May 31, 2005
  2. chris

    Local DTDs: Where?

    chris, Aug 14, 2003, in forum: XML
    Replies:
    3
    Views:
    391
    Bob Foster
    Aug 16, 2003
  3. Clifford W. Racz
    Replies:
    4
    Views:
    2,035
    Clifford W. Racz
    Feb 13, 2004
  4. seven.reeds
    Replies:
    2
    Views:
    705
    seven.reeds
    Jul 1, 2007
  5. D McGilvray
    Replies:
    2
    Views:
    369
    D McGilvray
    Aug 1, 2007
Loading...

Share This Page