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

Re: Expert's advice needed about XML Schema and defining some


som xml schema gui
Henrik Martensson wrote:

Hi and thanks for your comments. [more inline]

> On Fri, 2003-12-05 at 15:50, Robert Koberg wrote:
<snip/>
> 
>>and here is a the content piece referenced/identified in the content 
>>elements above (c123.xml):
>><article>
>>   <p>blah blah <link page_idref="a234">blah</link>
>></article>
> 
> 
> Here things go a bit weird, in my dochead opinion. If article is the
> root element of c123.xml, then c123.xml and the site.xml file must both
> be imported into the same file before validating the article.
> 
> It looks as if the system has very tight couplings where it shouldn't.
> An article can't be validated on its own, and is tied to the web site
> were it is published. I realize that for a brochure site that is
> completely self contained, this may not matter much, but as a generic
> design model, it does not work very well.
> 
> Again, XLink, or another link model with a similar purpose, would have
> felt more natural here, and would have enabled a simpler, more flexible
> design.
> 
> It is worth noting that in general it is a good thing to keep structural
> validation and link validation separate. It is necessary to be able to
> validate the structure of a document at the time it is written, at least
> for anything even moderately complex. On the other hand, external
> resources the document refers to may not be available when the document
> is written. Indeed, they may not even exist, because a document may
> refer to some other document that has not been written yet. In such
> cases, and they are frequent, tying link validation to structure
> validation would be a big mistake.

As I mention below the idref is *not* defined in the content schema as 
an xs:IDREF. It gets /validated/ by using XSL which basically renders a 
report of 'broken ' links (which should never happen if strictly using 
our tool). When indexing an xml document for search the link/@page_idref 
is set as a field and a search is performed in the app before a site.xml 
'page' can be deleted; if linked the the link must be removed/changed 
before the page can be deleted. If that somehow fails, the rendering XSL 
simply does not render it as a link but as inline text.

The idref is used in rendering to create an 'always valid' html:a/@href 
by traveling back up from the ref'd page in the site.xml hierarchy. This 
means when a page or folder is moved and the site is regenerated the 
html:a link is always valid for internal pages.

As for reuse, there is the option of putting a site_idref, but I 
understand what you are writing and I do agree that it is a limitation. 
I have not hit it as our current clients have no cross-site needs, but I 
assume I eventually will. I just haven't found a better way to do it and 
keeping the advantages.

> 
> <snip>
> 
>>In addition and among other things, I ocassionally validate that the 
>>content pieces referenced in the site.xml//page/region/content exists in 
>>topics.xml/topics//content (automated).
>>
>>site.xml/site//folder has the index_page attribute which is an xs:IDREF 
>>while site.xml//page/@id is an xs:ID.
>>
>>c123.xml//link/@page_idref is not defined in a schema as an xs:IDREF. 
>>Rather, I use XSL to verify that the 'virtual page' (to be rendered as 
>>HTML to the file system or sent back to a browser) that the content 
>>piece attempts to link to actually exists in the site.xml.
>>
>>If the above is understandable (:-o), am I following bad or good practices?
> 
> 
> Yes it is understandable. It is not the way I would have designed it,
> but it works and it isn't to complex.

There is a little more to it :)

> 
> What I have against the design is that it locks out standard tools and
> techniques. 

it can most definitely use standard tools. The client can pick up all 
their assets (and generated HTML) and edit/generate their site on their 
own using a number of different techniques -- it is very flexible. We 
can provide an XSL that transforms the site.xml/topics.xml into a 
Jakarta Ant build file which is used to generate the site. (I don't mind 
sharing this, but have not had the time to create a sourceforge project 
or the like. I would love it if it would become a standard :)

 > How does an XML editor validate an article?

The content pieces can be validated individually, the link validation is 
separate. Any XML Schema validating editor can be used (even MSWord now 
:). In our gui, we use MSXML in the browser for validation and its SOM 
to give editors valid options on the client and occasional validation on 
the server (xerces). I usually use Oxygen -- a really nice tool (even 
supports RNG).

> For that matter,
> how does an authoring application validate an IDREF link when the target
> is in another document? 

as I mention above, it is done in a few ways: by using XSL and putting 
it in a search index. I am definitely open to better ways to do this.

The UI presents the user with a grouped (by things like /folder1/folder2 
etc) dropdown of available site.xml pages. so if using the our gui, they 
cannot put in an invalid internal link.

> How do you reuse content that is currently
> published on this web site somewhere else, where the publishing
> mechanism is entirely different? 

If the content piece has an internal link, and that link should not 
point to the original site's page, then yes, it is a problem. I don't 
know how to solve it and keep the benefits I get from doing it this way.

> Again, these considerations may not be
> relevant for everyone, but they certainly are to me and the systems I
> work with.
> 
> Most of the differences in our respective approaches, is probably due to
> the fact that we work with different things. I am mainly concerned with
> content creation, and you (it seems to me) with publishing. Also, we
> deal with different kinds of information, a brochure and the technical
> documents I work with are very different. It is only natural if we have
> different perspectives and come up with widely different solutions to
> similar problems.

We are trying to provide a solution to small/medium-size 
businesses/departments which do not (in my experience) have a great need 
for content reuse outside of their site. Their needs are usually pretty 
basic and generally don't even know that they are using XML. They 
occasionally login (we are an ASP CMS) to add some content, wordsmith or 
add a folder/page. I tend to think of our business model similar to that 
of a health club -- in that their is usually a flurry of activity 
initially, then it tapers off to popping in once a month or so.

When I need to change the system (which I do rather frequently), I can 
transform the config/content XML, perhaps transform the XSL, make the 
appropriate modifications to the schema and validate everything to 
ensure it will work properly. It allows us (my wife and I) to manage a 
large number of projects very easily. I have found (over the last 3 
years) using this approach to be very efficient.

thanks again,
-Rob

> 
> /Henrik
> 



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.