[
Lists Home |
Date Index |
Thread Index
]
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
>
|
