RE: Content-in-RDF stable draft

Hi Johannes,

> >>> - There's no possibility of specifying the encoding of the
> TextContent.
> >> On the other hand if we provide encoding properties for both
> (XMLContent
> >> already has its own)  we will be suffering the same double-enconding
> >> problems we had
> >> discussed before.
> >>
> >> The xmlEncoding property specifies the _declared_ character encoding
> (in
> >> the XML declaration), not the _used_ encoding. Text content in general
> >> has no character encoding declaration.
> 
> However many (not all) texts are transformed from a byte sequence using
> a character encoding. So it may make sense to have an optional property
> for the actual character encoding in TextContent and XMLContent.

Think so.

 
> > Does it then make any sense to keep a character encoding that doesn't
> match the real one?
> 
> IMHO, it does.

OK.


> > Additionally the transcodification problem still remains.
> 
> Could you please elaborate on that?

It just remind me the problem we already faced while working on the HTTP Vocabulary in RDF and the body property [3]

[3] - [http://www.w3.org/WAI/ER/HTTP/WD-HTTP-in-RDF-20070301#body]

 
> >>> - The "Extensions" section reads "Classes to specify the Document
> Object
> >> Model (DOM) of XML documents". DOM core is applicable to XML, HTML or
> even
> >> CSS documents [1],
> >>
> >> Although the referenced note says so, a CSS "document" has no nodes, no
> >> elements, no PIs, etc. So DOM Core does _not_ apply to CSS.
> >
> > Maybe not the core as is, but it's apparently clear that DOM does apply
> to CSS [2] to certain extend.
> 
> I would say, "there is an Object model for CSS as well" [2]. :-)
> 
> > Don't see any comment regarding HTML so I suppose you agree on that.
> 
> Think so. Maybe CarlosV has some thoughts on it.

Anyway, I think that all classes to specify the DOMs of XML, HTML and CSS documents, whatever the DOM model it is, are interesting for our use cases and we may include them as possible extensions.


> >>> as they are very important formats for our uses cases I think we
> should
> >> reword this phrase to include them.
> >>
> >> BTW, we talked about using XMLContent also for storing the DOM created
> >> from HTML.
> >
> > I recall the discussion about the possibility of a DOMContent structure,
> but not about reusing XMLContent for this :o/
> 
> I think someone (maybe me :-] ) said, that XMLContent could be used for
> RDFying a serialization of an HTML DOM as well as an XML DOM. However
> there are issues with recreating the DOM from this serialization if
> there is a referenced HTML document type definition.

Don't remember the discussion, but at a first glance looks like a strange workaround for what should have it's own representation. Anyway I think it's something we can see at a later stage.

 
> >>> - The xmlRest definition reads: "Property representing as an XML
> Literal
> >> the part of the XML following the document type declaration if there is
> a
> >> document type declaration, or the part following the XML declaration if
> >> there is no document type declaration."
> >>
> >> Comments, PIs and the root element could be mentioned here.
> >
> > In fact I didn't finish my comment on the last message. What I meant is
> that I think the definition is not complete nor determinative because,
> AFAIR, the DTD and XML declarations are both optional, so if you don't
> have any of them, what's then the xmlRest?
> 
> Right. So we add: "or the whole XML if there is neither XML declaration
> not document type declaration."

Good!


Regards,
 CI.

___________________

Carlos Iglesias

Fundación CTIC
Parque Científico-Tecnológico de Gijón
33203 - Gijón, Asturias, España

teléfono: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Wednesday, 5 March 2008 11:36:48 UTC